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Preface 



This manual is designed as a technical reference for the 
Hewlett-Packard 12792A Eight Channel Asynchronous Multiplexer 
Subsystem for M/E/F-Series HP 1000 Computers. The Multiplexer 
interface is an efficient, high performance interface for multiplexed 
terminal/device applications. It enhances terminal communications by 
offering a low cost/channel, high speed, high performance alternative 
to other point-to-point interface offerings. 

This manual is intended for users knowledgeable in FORTRAN and the 
RTE-MIII or RTE-IVB operating system. The following is a brief 
description of each chapter's content. 

The OVERVIEW provides general information concerning the multiplexer 
subsystem and its interrelationships with HP 1000 products. 

The USER INTERFACE outlines the control functions used to perform data 

transfers to and from external devices, in addition to the control 

functions necessary to accomplish I/O control. Examples are provided 
for each control request. 

Using the features of the multiplexer and error handling/recovery is 
discussed in Chapter 3, USING THE MULTIPLEXER. 

The DEVICE DRIVER chapter is directed at the advanced programmer who 
is experienced with Assembly language. It provides the user with a 
tutorial on device driver writing. 

The DEVICE SPECIFIC CONSIDERATIONS chapter explains the interfacing 
requirements for using a non-HP device in the multiplexer subsystem. 
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Chapter 1 
Overview 



The Hewlett Packard 12792A Eight Channel Multiplexer Subsystem and its 
accessory, the HP 12828A accessory panel, provide communication to the 
computer through a microprocessor-based interface. The multiplexer 
significantly off-loads routine communication management overhead. 
The Multiplexer is used to route data from one of eight I/O devices to 
a common destination. One possible MUX configuration is shown in 
Figure 1-1. 
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Flexibility is a key feature of this product in that the users can 
connect devices such as terminals, printers, and "black boxes" to the 
MUX, provided the device meets RS-423-A or RS-232-C requirements. 
Furthermore, users can write device drivers for these devices attached 
to the MUX to handle any special control required by the device. 

Device drivers are simply subroutines of the interface driver which 
are used to modify user requests and make them compatible with a 
specific device. The interface driver, on the other hand, is 
basically responsible for the transfer of information between the user 
programs, the appropriate device driver, and the interface card. 

Each channel of the Multiplexer has a device driver associated with 
it. The device driver performs the device specific formatting of 
data, specifically, the inclusion of control characters for device 
requirements. When an EXEC call is issued from the user program, the 
interface driver passes it to the device driver. At this point the 
device driver can break up the user request into a series of interface 
requests. For example, the device driver can instruct the interface 
driver to wait for a buffer and inform the interface driver of the 
buffer's destination. The information is taken from the appropriate 
channel buffer and sent to the destination indicated by the device 
driver. 

Up to 14 device drivers may be used, each of which can be associated 
with one or more devices attached to one of the MUX cards in the 
system. HP supplies two device drivers with the 12792A 
product — DDV05 (26XX terminal screen mode device driver) and DDV12 
(2631/2635/7310 line printer device driver). 

Each Multiplexer interface card contains 16K bytes of Random Access 

Memory, of which 8K bytes are allocated for channel buffers. This 8K 

portion of memory is divided so that each channel contains four 254 

byte buffers, two for transmission and two for reception. Each 

interface card provides two on-board programmable baud rate generators 

which control channel transmission speeds ranging from 50 to 19. 2K 

baud. The total aggregate throughput must not exceed 78. 6K baud. 

This card may be inserted anywhere in the backplane of the CPU, unless 

there is a privileged interrupt fence. In this case the interface 

card should be inserted above the fence. The maximum number of 

physical devices which will be supported in the Multiplexer Subsystem 

is 61 (RTE-IVB) or 62 (RTE-MIII) . There are 63 available EQT's in the 

system but one EQT should be reserved for the system console and one 

for the disc. The Multiplexer does not offer system console support. 

To increase the throughput of the interface card Direct Memory Access 
is used. If the terminal/device channel is unable to obtain a DMA 
channel the device driver is placed into a loop to perform read/write 
functions on a word-by-word basis. 
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The HP 12828A multiplexer panel contains eight RS-232-C ports. The 
standard accessory panel is hardwired connecting port to one baud 
rate generator, and ports one through seven to another baud rate 
generator,. 

The Multiplexer Accessory Panel is connected to the interface card and 
can be located locally at the CPU (with the standard cable) or up to 
91 metres (300 feet) away from the CPU with custom cabling. RS-232-C 
compatible devices can then be connected to the Multiplexer panel by 
cables less than 39.7 metres (50 feet) in length. 

The MUX will passively support asynchronous, full duplex modems. 
Passive support means the MUX does not recognize or supply any modem 
control or status lines. The RS-232-C connectors on the HP 12828A 
have modem "Clear to Send" connected back to "Request to Send" and 
"Carrier Detect" wired back to "Data Terminal Ready." ("Data Set 
Ready" is pulled to +12v through a IK ohm resistor for those terminals 
that require it.) Use of the HP 12828A or connectors similar to these 
allow the passive support of modems. The user should be aware that 
"Line Loss" or other "Modem Not Ready" problems cannot be detected by 
the MUX or user software through the MUX. Modem connect or disconnect 
sequences cannot be requested through the MUX. 
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Chapter 2 
User Interface 



General Considerations 



This section describes the driver as seen by the user. Standard I/O 
EXEC calls are used to transfer data to and from external I/O devices 
in addition to performing various I/O control operations. Input, 
output and control requests to the multiplexer are generally in the 
form of RTE EXEC calls while control requests can be initiated either 
from EXEC calls or by using the file manager CN command. EXEC calls 
can be made from Assembly Language programs or from higher level 
languages such as FORTRAN and PASCAL. 



Request Code 



Parameter ICODE identifies the type of EXEC call request, 
eight types of EXEC calls described in this manual; four 
EXEC calls and four Class I/O EXEC calls. 



There are 
normal I/O 



STANDARD EXEC CODE PARAMETERS 



ICODE = 1 
ICODE = 2 
ICODE = 3 
ICODE = 13 



READ REQUEST 
WRITE REQUEST 
CONTROL REQUEST 
I/O STATUS REQUEST 



CLASS I/O EXEC CODE PARAMETERS 



ICODE = 17 

ICODE = 18 

ICODE = 20 

ICODE = 19 



READ REQUEST 
WRITE REQUEST 
WRITE/READ REQUEST 
CONTROL REQUEST 
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Control Word 



Control word (ICNWD) contains a five bit function code and the logical 
unit number (LU) of the device to which the user request is directed. 
It is structured as follows: 



15 



10 



6 5 







X AK^V MiL L L 



L L L 



I < — function — > I < — logical unit-> 
dode number 



Function Code 



The octal value of the required function code is provided for each of 
the request descriptions in the following sections. The user may 
choose any of the methods described in this chapter to set the value 
of bits 10 through 6 of control word ICNWD. For example, if the 
function code value is octal 6, add 600B to the value of the LU 
number. 

The MUX driver examines the value of the function code to determine 
the action taken by the interface driver in the processing of I/O or 
device control. The requests will vary depending on the function 
codes described below. These function codes are used whenever an EXEC 
1 (Read), EXEC 2 (Write), or EXEC 3 (Control) call is made, although 
the bit meanings differ between read and write requests. Refer to 
Figure 2-1 for ICNWD bit names. 
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BIT 


10 


(X BIT) 


Transparent Mode Bit; 

- DISABLED 

1 - ENABLED 


BIT 


9 


(A BIT) 


Special buffer control bit; 

- DISABLED 

1 - ENABLED 


BIT 


8 


(K BIT) 


Echo Bit; 

- DISABLE 

1 - ENABLE 


BIT 


7 


(V BIT) 


Honesty Bit; 

- DISABLE 

1 - ENABLE 


BIT 


6 


(M BIT) 


Binary Mode Bit; 

- DISABLE 

1 - ENABLE 



Figure 2-1. ICNWD Function Code Bits. 



2-3 



Logical Unit Number 

The logical unit (LU) number is the system address for the I/O device 

to which the user is directing a request. The user's system 

generation listing enumerates the LU numbers of all I/O devices 
generated into the system. 

For example, if the LU number is decimal 10 and the function is octal 
6, the value of ICNWD can be computed: 

ICNWD = 10 + 600B 
The B suffix is used to identify "600" as an octal number. 



I/O Requests 

I/O requests are handled in a variety of ways. These requests are 
processed differently depending on the value of the control word. 
Three basic input functions are controlled by the value of ICNWD. 

- editing 

- echoing 

- terminators 

When editing is enabled, the control word bits 6 and 10 are set to 
zero. If a delete key (rub out key) is struck, the contents of the 
user's receiving buffer is erased. The backspace key deletes only the 
last character entered, if any. If editing is disabled, the delete 
and backspace keys would enter a 177B or 12B into the user's on-board 
buffer. 

If a user is inputting data with editing enabled the interface card 
will accept the data into one of the channel's input buffers. The 
multiplexer handles all the edits. User input and editing can 
continue until the card's buffer is full or a valid terminator is 
detected. At this point the on-board buffer is off loaded to the CPU. 
Once the buffer has been moved it cannot be edited. For this reason 
the user cannot backspace or delete past a 254 byte boundary. 

In general, information is supplied to the Multiplexer card in a 
character mode format and echoed back to the user for visual 
inspection of the buffer. This is not always desirable; the echo 
feature may be suppressed for passwords and special requests. 
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The Multiplexer card must be able to detect an end-of-record or valid 
terminator when it is encountered. Figure 2-2 lists the valid 
terminators used to signal the card to interrupt the CPU and transfer 
data to the user's buffer. 

Figure 2-3 describes the control word bit combinations used to 
determine the interface driver's action on a read request. It is here 
that valid terminators, as well as input editing and echoing are 
specified. Figure 2-4 describes the valid buffer transfer 
terminators. 



COMMON NAME 



OCTAL VALUE OF 
RIGHT BYTE 



carriage return CR 

device control DC2 

record separator RS 

end of transmission EOT 



000015 
000022 
000036 
000004 



Figure 2-2. Valid Terminators 
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ICNWD BITS 



10 9 8 







X 



1 



X 







X 1 



1 



X 1 







1 



1 * 



X 



X 



X * 



ACTION TAKEN FOR READ REQUEST 



editing enabled - 

echo disabled 

CR is a valid buffer transfer terminator 

CNTRL D results in an EOT status condition 

and a zero length transmission log (zero 

length buffer) 

input editing enabled 

echo enabled 

CR is a valid transfer terminator 

CNTRL D results in an EOT status condition 

and a zero length transmission log (zero 

length buffer) 

input editing disabled 
echo disabled 

data transfer terminates only when the user 
buffer is full 

input editing disabled 
echo enabled 

data transfer terminates only when the user 
buffer is full 

input editing disabled 

echo disabled 

CR is a valid transfer terminator 

input editing disabled 

echo enabled 

CR is a valid transfer terminator 



special buffer transfer 

same as the transfer with bit 9 (special 
function bit) set to zero but data 
resident in the card's buffer that 
exceeds the end of the user buffer 
not destroyed. It may be accessed 
subsequent buffer transfers. 

echo, edit, etc. are defined by bits 6, 
and 10 above. 



IS 

in 



8, 



X = don't care condition 



Figure 2-3. Read Request Function Codes. 
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ICNWD BITS 








10 9 


8 


7 


6 


WRITE REQUESTS 


X 


X 


X 





An ASCII write request will have CR/LF 
appended to the buffer if the last 
character in the buffer is not " "• 
If the underscore, 00137B, is appended to 
the user's buffer it will not be printed. 


X 


X 


X 


1 


the entire buffer is transmitted as is. 


1 X 


X 


X 





no characters are appended to the user's 
buffer. 

X = don't care condition 



Figure 2-4. Write Request Function Codes. 

There are some areas of I/O request handling that require special 
mention: 

Zero-length keyboard entries will not be ignored by the interface 
driver. A carriage return without data is a zero length record. 

Control function 30 configures the Multiplexer card to conduct 
I/O transfers in a specified character format. The terminal must 
be configured accordingly for successful I/O processing to occur. 



Standard I/O EXEC Calling Sequences 

The following sections show the general formats used for making EXEC 
calls from RTE Assembly, RTE FORTRAN IV and PASCAL/1000 programs. In 
the following examples, the only names that must be used as given are 
EXEC and ABREG. Other parameters used such as ICODE, ICNWD, and IPARM 
are simply mnemonics used in this manual. 
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EXEC CALLS from Assembly Language 

The Assembly language calling sequence for EXEC calls is as follows 



EXT EXEC 



Declare EXEC as an external 





JSB 


EXEC 




DEF 


RTN 




DEF 


ICODE 




DEF 


ICNWD 




DEF 


IPRl 




DEF 


IPR2 


RTN 






ie 






* 






* 







Transfer control to RTE 

Return address 

Request code 

Control word 

Parameter 1, optional 

Parameter 2, optional 

Return Point 

A register contains I/O status 
B register contains the length of the 
transmission log 



ICODE 
ICNWD 



DEC 1 
OCT CNWD 



Request code word (READ) 
Control word. Control function 
+ LU number assigned to the port. 



IPRl 
IPR2 



OCT prl 
OCT pr2 



Use depends on 
type of call 



The return point, labeled RTN, must follow the DEF of the last 
parameter used. EXEC uses this address to calculate the number of 
parameters passed for those calls that have optional parameters. 
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EXEC CALLS from FORTRAN 

To call EXEC as a subroutine from RTE FORTRAN IV, use the following 
calling sequence: 



ICODE = 3 

ICNWD = 600B + LU 



CALL EXEC ( ICODE , ICNWD, I PARMl , IPARM2) 
CALL ABREG(IA,IB) 



EXEC can also be called as a function from RTE FORTRAN IV, using the 
following calling sequence: 



DIMENSION IREG(2) 

EQUIVALENCE (REG,IREG) , (IA,IREG) , (IB,IREG(2) ) 



REG = EXEC (ICODE, ICNWD, I PARMl, I PARM2) 



The two different methods of calling EXEC from FORTRAN illustrate the 
two ways of obtaining the A- and B-Register values from the EXEC call. 
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In the following sections, the examples used to illustrate the calls 
are written using the CALL EXEC(...) method, with an example showing 
how to make the control request from the File Manager using the CN 
command. 



EXEC CALLS from Pascal 



An EXEC call may be coded in PASCAL/1000 either as a procedure or as a 
function. If it is coded as a function, the return value type must be 
a one-word type to return the values of both the A- and B-Registers. 

The PASCAL/1000 compiler does not treat an EXEC call in any special 
manner. Therefore, it is possible to call EXEC directly if an 
external declaration has been made with a set of formal parameters. 

If the $HEAP 2$ compiler option is used, then the HEAPPARMS option 
must be OFF for EXEC external declarations with VAR parameters. 

Example: 



program muxex; 
const 



type 



lu_control_request_code = 3 ; 

shif t_lef t_six_bits = 64 ; 

lu_n umber = 19 ; 

function code = 6 ; 



int 


== -32768. .32767; 


bit 


= 0..1; 






bit 


def = packed 


record 




bit 15 




0..1 




bit 14 




0..1 




bit 13 




0..1 




bit 12 




0..1 




bit 11 




0..1 




bit 10 




0..1 




bit 9 




0..1 




bit 8 




0..1 




bit 7 




0..1 




bit 6 




0..1 



{ EXEC 3 , a control request } 

{ is placed on LU 19. The 16 } 

{ bit control word is stripped} 

{ of bits 15 -11, so that the } 

{ function code, bits 10-6, } 

{ can be examined. In this } 

{ case the function code 6 } 

{ is placing a status request } 

{ to LU 19 } 



{ single-word integer type 

{ single-bit type 

{ bit data type 

{ This allows the user to 

{ access each bit field 

{ individually. 
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bit 5 : 


0..1 


bit 4 : 


0..1 


bit 3 


: 0..1 


bit 2 


: 0..1 


bit 1 


: 0..1 


bit 


: 0..1 



end; 

word_def = record 

CASE int of 



( bits 
( word 



end; 



{ word data type } 

bit_def ) ; { this double definition } 

int ) ; { allows the user to access } 

{ the information bit by bit} 

{ or as a word } 



var 



control_word 

sub_f unction 

a_reg 

b_reg 

SI 



int; 

word_def ; 
word_def ; 
word_def ; 
text; 



procedure rte_exec_call $alias •EXEC'$ 

(request_code : int; 
var control_request : int; 
var subfunction : word def ) ; 



external ; 



procedure get_the_a_b_registers $alias »ABREG'$ 

(var a:word def; var 



word def); external; 



procedure initialize_sub_f unction; 

begin { initialize optional parameters } 



sub_f unction. bits. bit_l 5 
sub_function.bits.bit_14 
sub_f unction. bits. bit_l 3 
sub_function.bits.bit_12 
sub_f unction. bits. bit_ll 
sub_f unction. bits. bit_10 
sub_f unction. bits. bit_9 
sub_function.bits.bit_8 
sub_f unction. bits. bit_7 
sub_f unction. bits. bit_6 
s ub_f unction. bits. bi t_5 
sub~f unction. bits. bit_4 
sub function. bits. bit 3 
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s ub_f unction. bits. bi t_2 

sub_f unction. bits. bit_l 
sub function. bits. bit 



= 

= 
= 



end; 



begin { beginning of main program } 



initialize_sub_f unction; 
sub_function.bits.bi t_l 
sub_function.bits.bit~3 
sub_f unction. bits. bit_5 
sub_f unction. bits. bit~7 
sub function. bits. bit~9 



{ set the appropiate bits } 
{ in the optional parm } 



} 

{ construct the control word } 

control__word := lu_number+(f unction_code*shif t_lef t_six bits); 
{ place the RTE EXEC call } 

rte_exec_call (lu_control_request_code, 

control_word, sub_f unction) ; 

get_the__a_b_registers (a_reg ,b_reg) ; 

begin { examine the A-register for the status of this channel } 

reset (Sl,'l'); 
{ 



} 

if a _reg.bits.bit_15 = 
then 

if a_reg.bits.bit_14 = 

then 

writeln (SI, 'unit available for use') 
else 

writeln (SI, 'unit disabled') 
else 

if a_reg.bits.bit_14 = 
then 

writeln (SI, 'unit currently in operation') 
else 
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writeln (SI, 'unit waiting for DMA channel'); 
{ 



} 
end; 
end. { end of PASCAL example } 



It may be necessary or desirable to use aliases for each EXEC service 
used in a program for the following reasons: 

- The name EXEC represents an entire class of services. A 
program using EXEC calls will be more readable if a descriptive 
PASCAL/1000 name is given to each service. 

- Each EXEC service requires a different set of parameters. Some 
services (e.g., EXEC 11) have optional parameters. Each 
PASCAL/1000 routine must have a specific set of parameters. 



EXEC CALL Parameters 

Request code ICODE and control word ICNWD, in that order, are the 
first two parameters of an EXEC call. Other parameters, when needed, 
are described for each request in the following sections. 



Control Requests to the MUX 

Control requests have the following general format: 
CALL EXEC (ICODE, ICNWD, I PARM) 

Request code ICODE has a value of 3 for all control requests. Each 
control request has a different function code specified in ICNWD, and 
the value of the IPARM parameter depends on the function code. Table 
2-1 contains a summary of the function codes and their meanings. 

Equipment Table word five (EQT5) contains the status word. If a 
control request is made to an unbuffered EQT, the A-register will 
contain the device's status. If the EQT is buffered, the A-Register 
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is meaningless. In either case the B-Register is meaningless, except 
for control function 6. This status request will return the length of 
the type-ahead data in the B-register. 

When issuing a control function command from the File Manager the 
following format is used: 

:CN,lu,fn[,pr] 

lu = LU number 

fn = control function code 

pr = optional control parameter 

For example, to place LU 19 in type-ahead mode with cancel on break, 
the following control command is issued. 

:CN,19,33B,23000B 



Table 2-1. Control Function Codes 



CODE 


DESCRIPTION 


PARAMETERS REQUIRED 


6B 


DYNAMIC STATUS OF PORT 


NO 


20B 


ENABLING SCHEDULING 


NO 


2 IB 


DISABLE SCHEDULING 


NO 


2 2B 


SET TIMEOUT 


YES 


23B 


BUFFER FLUSH (OUTPUT) 


NO 


24B 


BUFFER UNFLUSH 


NO 


26B 


FLUSH INPUT BUFFER 


YES 


27B 


SET PROGRAM ADDRESS 


YES 


30B 


SET PORT'S ID 


YES 


3 3B 


CONFIGURE DRIVER RESPONSES 


YES 


37B 


SET READ TYPE 


YES 
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Device Initialization 

Device initialization is accomplished by executing the following three 
control functions to enable terminals. Normally this is done for each 
terminal from your WELCOM file, but can be executed interactively. 

- set port ID (required) 
function 30 

- configure driver responses (optional) 
function 33 

- enable scheduling (optional) 
function 20 



Set Port's ID (Control Function 30) 

Control function 30B establishes a logical connection between the 
logical unit ajid the physical terminal connected to the interface. 
This function is normally executed from the WELCOM file to initialize 
and configure ports through 1, but can be done interactively. 
Function 30 must be issued before any other request is given to that 
port. If other commands are sent prior to this function call they may 
be ignored. 

The value of IPARM for control function 30 is defined as follows: 

Bits 15-14: # bits per char for tra*hsmission and reception. 
This does not include parity. 

0=5 bits/char 2=6 bits/char 
1=7 bits/char 3=8 bits/char 

Bit 13: Reserved for future use and should be set to zero. 

Bit 12: Baud rate generator for this port: 

= baud rate generator 

1 = baud rate generator 1 
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Bits 11-10: # stop bits: 

All data transfers to and from the interface card 
require a delay between each character. For all 
asynchronous transfers there is always at least 
one stop bit. 

= reserved 2 = 1-1/2 bits 
1=1 bit 3=2 bits 

Bits 9-8: Parity select: 

= none 2 = none 

1 = odd 3 = even 

Bit 7: 1 = ENQ/ACK handshake enabled 
= handshaking disabled 



Bits 6-3: 


BAUD rate: 













= no cha 


nge 


8 = 


1800 




1 


= 50 




9 = 


2400 




2 


= 75 




10 = 


4800 




3 


= 110 




11 = 


9600 




4 


= 134.5 




12 = 


19200 




5 


= 150 




13 = 


reserved 




6 


= 300 




14 = 


reserved 




7 


= 1200 




15 = 


reserved 



NOTE: 

All ports on a Baud Rate Generator must be initialized to 
the same baud rate. The user should be certain that all 
ports have their baud rate set using this function, 
regardless of the baud rate at which the terminal is 
strapped. In addition, 19200 baud is not supported on 8 
channels simultaneously since it would exceed the maximum 
throughput of the card (78600 baud) . A baud rate 
parameter of zero will not change any of the port's 
parameters (baud rate, parity, stop bits, etc.). 

Bits 2-0: Port number of this terminal (0-7) 

For example, to set the port ID of an HP 2621 terminal on channel 0, 
as LU 41, with a baud rate of 9600, ENQ/ACK handshaking enabled, and 
no parity the following control request is issued: 

CN,41,30B,142330B 
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Configure Driver Responses (Control Function 33) 

Control function 33B uses the IPARM parameter to specify port 
parameters. The value of IPARM will configure the driver without 
sending the parameters to the card. The bit fields are defined as 
follows (all fields default to the 01 state at system boot time) : 

Bits 15-14 Reserved for future use, should be set to zero. 

Bits 13-12 These bits define the type-ahead feature of the MUX card. 

00 = no change 

01 = (default value) no type-ahead. Striking any key 

when there is not a read request pending will gain 
the system's attention, if enabled. 

10 = Type-ahead data can be received without a pending 
read request. The information on the card is saved 
until a read request is made. At this point the 
data is retrieved. Only the break key will gain the 
system's attention unless type-ahead with scheduling 
is enabled. 

Bits 11-10 These bits define the action to be taken when type-ahead 
data becomes available. Type-ahead data is defined as 
"available" when an End-of-Record is read by the card. 
Valid terminators are defined by the previous read or 
through control request 37. 

00 = no change 

01 = (default value) bit 2 is set in the EQT status word. 

10 = Bit 2 is set and scheduling is attempted. 

Bits 9-8 These bits define the action to be taken when the BREAK 
key is struck. 

00 = no change 

01 = (default value) if scheduling has been enabled via 

control 20, scheduling is attempted. 

10 = cancels any type-ahead data and then attempts to 
schedule the designated program. 
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Bits 7-6 These bits control the sending of read configuration 
information to the card. Also see control 37B. 

00 = no change 

01 = This is a normal read operation. The driver 

examines bits 10-6 of the control word in the user's 
EXEC request which specifies a unique read request 
type to the MUX card. 

10 = This will not reconfigure the read operation. When 
bit 7 is set, the driver overlooks bits 10-6, and 
only the device driver or a control 37 can modify 
the read configuration type. 

Bits 5-4 Reserved for future use, should be set to zero. 

Bits 3-0 These bits define the device driver attached to this 
port. Device driver number one is the default device 
driver which passes all of the user's requests directly 
to the interface driver. Other device drivers are 
defined at system generation time. The device driver 
address table $DVTB is established at generation time and 
defines which device driver has what device driver number 
associated with it. Exactly one device driver is 
attached to each port at any time. If zero is entered no 
change is made. 

For example, to configure the driver response for a full type-ahead 
mode on the terminal/device associated with LU 41: LU 41 has device 
driver #3 (DDV05) attached to port 0. 

I CODE = 3 

ICNWD = 3300B441 

IPARM = 022400B 

CALL EXECdCODE, ICNWD, IPARM) 

• 

OR 
CN,41,33B,022400B 

NOTE: If any port is configured for a type-ahead mode, the break key 
must be struck to schedule the LOGON prompt. 
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Enable Scheduling (Function 20) 

Control function 20B enables the driver to schedule a program on 
interrupt. The program to be scheduled is specified at generation or 
the driver can interactively be informed of the address of the 
program's ID segment through control function 27. Scheduling will 
commence if the following conditions are met: 

1. Scheduling is enabled 

2. The program to be scheduled is dormant (state 0) 

3. A read operation is not in progress. 

4. The port is not in type-ahead mode and any key is hit 

-or- 

The port is in type-ahead mode and the break key is hit (see 
control 33 regarding type-ahead and the break key). 

-or- 

The port is in the type-ahead mode with "scheduling on data 
available" and a valid terminator, or count, is received. 

To enable scheduling and schedule a program on an unsolicited 
interrupt the following request is issued: 

I CODE = 3 

ICNWD = 2000B+LU 

CALL EXEC (ICODE, ICNWD) 

or to enable scheduling on an unsolicited interrupt at LU 41: 
CN,41,20B 



2-19 



Other Interface Driver Control Requests 



Disable Schedule (Function 21) 

Control function 21 resets the flag set by control function 20 (enable 
scheduling) . When a terminal is disabled, striking a key on the 
keyboard will not schedule the program specified at generation or by 
control request 27. Once a port is disabled, programs will not be 
scheduled. At boot-up time the default value of the schedule enable 
flag is disabled. 

For example, to disable LU 41: 

ICODE = 3 

ICNWD = 2100B + 41 

CALL EXEC (ICODE, ICNWD) 

• 

OR 
:CN,41,21B 
To re-enable the terminal an "Enable Schedule" request must be issued: 
:CN,41,20B 



Set Timeout (Function 22) 

To alter the RTE device time-out value that was established at system 
generation, use control function 22B. The time-out value can be set 
in 10 millisecond intervals by the integer provided as an additional 
parameter. 

Time-out values can also be set by using the system TO command. The 
RTE Programmer's Reference Manual describes how to use the TO command. 
When using a control request or the File Manager CN command, be sure 
to specify the channel or device by LU number; when you use the TO 
command, specify the channel by the EQT number. The TO command checks 
for a lower limit of 500 ms but control function 22 does not„ 

The timer specifies the number of tens of milliseconds to wait for 
keyboard input. If this time is exceeded before a user keyboard input 
completes, the driver sets bit 7 in the terminal's status byte and 
returns to the caller with a zero length transmission log. 
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For example, to set the timeout of LU 41 to 25 seconds: 

I CODE = 3 

ICNWD = 2200B + 41 

ITO = 100 * 25 

REG = EXEC (ICODE, ICNWD, ITO) 

• 

OR 
CN,41,22B,2500 

Buffer Flush (Function 23) 

Issuing a control request to a specified LU with a function code of 
23B will place that LU's port in the buffer flush condition. In this 
condition, the driver ignores all write requests for the designated 
port. 

The buffer flush condition is removed automatically when a read 
request is processed or the pending request queue on the EQT is empty. 
The buffer flush condition may also be removed by issuing the "Buffer 
Unflush" control request. 

The following is an example of establishing a buffer flush condition 
on LU 41: 



ICODE = 3 

ICNWD = 2300B + 41 

REG = EXEC (ICODE, ICNWD) 



OR 
:CN,41,2 3B 



Restore Output Processing (Function 24) 

To remove a buffer flush condition, issue a control request with a 
function code of 24B. The Restore Output Processing function restores 
the ability to process write requests after a buffer flush condition. 
If the port is not in the buffer flush state, this call is ignored. 
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The following is an example of restoring output processing to LU 41 



ICODE = 3 

ICNWD = 2400B + 41 

CALL EXEC (ICODE, ICNWD) 



OR 
:CN,41,24B 



Flush Input Buffer (Function 26) 

Control function 26B instructs the interface card to clear any data 
from the channel's input buffer which might have accumulated in 
type-ahead mode. The value of IPARM indicates whether only the active 
buffer (IPARM=0) or all of that port's receiving buffers (IPARM=1) 
should be cleared. Note that this is not the same as Buffer Flush 
control function 23B. Control 26B ensures the user that the 
information requested is what is obtained, eliminating the possibility 
of processing any outstanding data previously entered. To flush only 
this channel's active buffer use IPARM=0. Setting IPARM=1 will flush 
the two 254 byte input buffers on this port. 

For example, to flush the two input buffers on LU 41: 

ICODE = 3 

ICNWD = 2600B+41 
IPARM = 1 

CALL EXEC (ICODE, ICNWD, IPARM) 

OR 
CN,41,26B,1 



Set Program Address (Function 27) 

Control function 27B saves the value of IPARM as the address of the ID 
segment of a program to be scheduled on an unsolicited interrupt. If 
the value of IPARM is zero or negative, program scheduling is disabled 
regardless of function 20 (octal). This call will override for this 
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particular port the value set at system generation time. This control 
function is intended for programmatic rather than interactive use. A 
program's ID segment address can be found using the system utility 
subroutine IDGET. Care should be exercised that the address supplied 
is correct and points to an ID segment of a permanently loaded 
program. For example, if lADDR contains the address of a program's ID 
segment, this program will be scheduled on an unsolicited interrupt. 

ICODE = 3 

ICNWD = 2700B+LU 

CALL EXEC(ICODE, ICNWD, lADDR) 

OR 
CN,LU,27B,IADDR 



Set Read Type (Function 37) 

Control function 37B sends configuration information to the interface 
card for use in read (EXEC 1) operations. Under normal operation, 
this information is provided by the interface driver as directed by 
the function field bits 10-6 of the EXEC request. This call provides 
the user with a mechanism to override the interface driver defined 
values or to configure a read operation on the card without executing 
a read request. This is useful in type-ahead initialization. If bit 
7 in the driver configuration word (control 33B) is not set, the next 
read operation will reset the read type. See Table 2-2 for a 
description of the SET READ TYPE parameter. 

For example, to establish a read type with a buffer transfer on a 
carriage return for LU 41: 

ICODE = 3 

ICNWD = 3700B+41 

ITYPE = lOOOOOB 

CALL EXECdCODE, ICNWD, ITYPE) 



OR 
CN,41,37B,100000B 
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Table 2-2. Set Read Type (Function 37B) Parameter Description. 



Bit # 



15 

14 
13 
12 
10-11 



8 
0-7 



Read Type 



buffer transfer on a carriage 
return <CR> 

buffer transfer on a record separator <RS> 

buffer transfer on control-D 

buffer transfer on DC2 

reserved for future use, 
should be set to zero 

enables input data editing 
(backspace and delete) 

enables input data echoing 

reserved for future use, 
should be set to zero 



Dynamic Status (Function 6) 



All requests to the MUX (EXEC 1, 2 and 3 calls) clear bits 3 through 7 
of the port's status. Control function 6B can be used to verify if 
program scheduling is enabled or type-ahead data is available. If 
program scheduling is enabled bit 1 would be set and if type-ahead 
data is available, bit 2 would be set in the A-register. Bits 0, 3-7 
would all be zero. The B-register can be examined to determine the 
length of the available type-ahead data. 
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An example of a dynamic status request to LU 42 is coded as follows: 

I CODE = 3 

ICNWD = 6 00B+4 2 

CALL EXEC(ICODE, ICNWD) 

CALL ABREG(IA,IB) 



The dynamic status request is a call to the driver; therefore, it will 
wait until any outstanding requests to that EQT have completed. 
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Chapter 3 
Using the MUX 



This chapter deals with using the features of the HP 12792A 
Multiplexer. Type-ahead is explained, and the most commonly used 
type-ahead modes are discussed. Error handling and failure analysis 
in user-written programs are also addressed. 



Normal Mode 

In the normal, non-type-ahead mode of operation, the subsystem will 
appear identical to other non-multiplexed RTE terminal drivers. When 
a port is inactive, the driver will leave an "interrupt on any 
character" read pending on the card so as to be informed when a key is 
struck. The appropriate action (system attention, program schedule, 
etc.) will then be taken. 



Type-Ahead 

Type-ahead is the ability of a system to accept data from the user's 

terminal or device before it is requested by the CPU. The MUX card is 

a buffered device and for each channel it is capable of holding up to 
two, 254 byte buffers of text in on-board memory. 

An advantage of type-ahead is that applications programs can make the 
system appear more responsive to the user, increasing TOTAL (human 
included) throughput. This is done by having the application program 
prompt the user for his/her next response while processing the 
previous one. By the time the user has finished typing, the system 
will have processed the last request and can begin on the next. As 
long as the processing takes less time than the typing, the user 
perceives instant response time. 

While in type-ahead mode, the driver leaves a read request pending on 
the CARD (not the EQT) at all times. This read allows the user to 
enter data into the card even though the SYSTEM does not have a read 
pending. Upon receiving a record the card will interrupt the CPU, 
telling it that a buffer of data is available. If no request has been 
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posted to that port, a flag is set in the status word and the driver 
returns to the system and waits. When a request is issued, the driver 
reads the data from the card and completes the user request. 

Since keyboard characters are buffered on the card, system attention 
in type-ahead mode cannot be gained by striking a terminal key. The 
BREAK keyp however, is not buffered and can be used to obtain system 
attention., 

Since multi-line type-ahead is possible, two different type-ahead 
modes are available. Full type-ahead, as described above, would cause 
successive read requests to fetch successive lines of text from the 
multiplexer card. This mode is useful for such tasks as text editing 
and using DBUGR. Typing can be done as far ahead of the data 
processing as allowed by available multiplexer buffer memory, up to 
and not exceeding two records. 

In situations where system response could radically alter a user's 

next command (FMGR error messages, for example) a full multi-line 

type-ahead may cause problems. The following will illustrate this 
problem: 

User types... ST, FILE, 8 

while tape is moving, the user types: 

PU,FILE 

the tape runs out; the system downs the device 

The user hits the BREAK key, the system issues a prompt and a 
read, the system rather than FMGR reads the PU command from card 
buffer, and tries to execute the FMGR command. 

In the above example, the user merely gets back an "OP CODE ERR" from 

the system the first time the request for system attention is made. 

It is possible, however, for the commands stored on the card to have a 
disastrous effect on the system. 

The solution to the above problem is to configure the driver to cancel 
all card data upon receiving a BREAK interrupt (see control function 
33B). This preserves the multi-line type-ahead feature, and reduces 
the chance of data being read by the wrong process. 

If an analogous situation could occur for user written programs, 
another possible solution is for the user to issue a Flush Card Buffer 
request (control 26B,1) prior to any sensitive read request. This 
will clear the extra commands before they can be misread. 

Note that type-ahead is also useful in non-terminal device 
communication. The buffering on the card eliminates the need for 
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stacking two or three class read requests on an LU to prevent data 
loss, thus reducing program size and complexity and the need for lots 
of SAM. Type-ahead scheduling can be used to invoke a data processing 
program. 

When data is available on the multiplexer card and there is no pending 
request to accept it, a bit is set in the status word and program 
scheduling will be attempted. Should the user program decide it 
doesn't want the data, it can issue an input flush (control 26B) to 
remove the data. 



Program Scheduling 

Program scheduling is a mechanism whereby certain external events will 
cause the interface driver to schedule a program in the system. This 
program is given the address of EQT word 4 which provides adequate 
information to determine at which port the event occurred. 

Program scheduling is an optional feature which must be enabled to 
operate. A set of control requests (Control 20B, 21B) are used to 
enable and disable this feature. An additional request (Control 27B) 
is provided to allow programmatic setting of which program is to be 
scheduled, overriding the program designated when the system was 
generated. 

There are several events which can cause a program to be scheduled. 
If the port has been set to "normal" mode (see Control 33B, bits 13, 
12) striking any character key or the BREAK key on a terminal keyboard 
(or the receipt of a character or BREAK from a device) will cause the 
character to be ignored and the designated program to be scheduled. 

A port which has been configured in type-ahead mode will require the 
receipt of a BREAK to schedule the program, because any characters 
received will be saved in the port's data buffers. The port can also 
be configured to schedule the program on receipt of a buffer of data 
from the device. This type-ahead with scheduling mode will still 
recognize the BREAK key. 

A program scheduled by one of the above events is run with the 
machine's B-register pointing to word 4 of the Equipment Table (EQT) 
entry corresponding to the port upon which the event took place. 
Library functions EQLU or TRMLU can be used by the program to recover 
the Logical Unit (LU) of that port. This LU can be used later to make 
I/O, Control, and status calls to that port. The library subroutine 
RMPAR can be used to recover EQT words 4 through 8. Note that both 
these routines require that the B-register set by the driver remain 
intact. 
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The programs PRMPT and R$PN$ are used for terminal break-mode command 
processing, and are supplied with most RTE systems. These programs 
are an example of the use of program scheduling. In operation, PRMPT 
is the program which gets scheduled on interrupt from the terminal. 
When invoked it finds the LU of the interrupting port and writes the 
break-mode prompt to that LU. It then posts a class read against that 
port and schedules the program R$PN$. R$PN$, waiting on a class GET, 
receives a command from the user and executes it, returning to suspend 
on the GET call for the next command. 

User supplied programs may be written to process other schedule-driven 
applications. These programs may either be included as the program to 
be scheduled when the system is generated, or assigned on-line by a 
control request. 



Common Type-Ahead Modes 

Control Function 33 allows the user to control the driver responses by 
manipulating four fields, specifying sixteen different type-ahead 
combinations. However, the four following combinations are sufficient 
for most user applications. If a specific application is desired, the 
user can design a mode by manipulating the control word's bit fields 
using control function 33. 

The common operating modes are: 

Normal Non Type-Ahead Mode 

Full Type-Ahead Mode 

Type-Ahead with Flush on Break Mode 

Type-Ahead with Scheduling Mode 

Each mode is summarized below along with the run string necessary to 
configure the user's terminal. Control requests and bit manipulation 
are discussed in the Interface Driver section. 
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No Type-Ahead Mode 



CN,0G,33B,012400B 



Control Parameters 



Control Request 



User's Terminal 



This will return the port to a 
commonly used in the WELCOM file 
configure the port to a specific 
while executing in this mode 



standard RTE mode. This mode is 

so that the individual may later 

application. If a key is struck 

and no request is pending on the 



terminal, the designated program will be scheduled. 



Full Type-Ahead Mode 



CN,0G,33B,022400B 



Control Parameters 



Control Request 



User's Terminal 

As discussed earlier, type-ahead is a mode of operation enabling the 
interface to accept strings of data from terminal devices even though 
the system did not request any information. This information is 
stored in one of the two 254 byte receiving buffers for that port and 
remains buffered until a program reads the contents of the buffer. 
While in type-ahead the driver leaves a read pending on the interface, 
looking for a valid terminator. The terminator merely signals the 
interface driver that a complete record has been encountered, and the 
interface card will interrupt the CPU. 

In this mode, the only way to schedule the designated program is to 
strike the break key. Data resident on the card, if any, is not 
disturbed. 
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Type-Ahead with Scheduling Mode 



:CN,0G,33B,024400B 

Control Parameters 
Control Request 
User's Terminal 



This mode configures the interface driver responses to utilize the 
type-ahead mode. Scheduling will occur when an end-of-record is 
encountered. Depressing the Break Key will always schedule the 
designated program. Program specification is accomplished with 
control function 27 or, more commonly, it is specified at generation 
time. 



Type-Ahead with Flush on Breal( IVIode 



ivb^ 



CN,0G,33B,023/000B 



Control Parameters 



Control Request 



User's Terminal 

In this mode when the break key is struck, the interface driver will 
flush the contents of the input buffers and then the program 
designated by control function 27 is scheduled. This mode of 
operation is the preferred type-ahead mode because 
possibility of having data misread. The user has 
"erasing" the contents of the buffers just entered 
break key or leaving the buffers alone allowing them 
the next read request reads them. 



it reduces the 

the option of 

by hitting the 

to execute when 



NOTE: Flush on break may be used in conjunction with either full 
type-ahead or type-ahead with scheduling. 
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Error Recovery 

Dynamic status checking and I/O status checking allow the user to 
check on the status of a Multiplexer port for normal processing and 
error checking. I/O status can provide the user with two of the 
device status words (EQT5 and EQT4) and an LU status word. Dynamic 
status checking provides the user with the port's status and the 
length of any type-ahead data if present. Control function 6 is 
described in the User Interface chapter. 

All errors associated with the Mux will appear as: 

- time outs 

- parity error or overflow 

Parity and overflow errors are indistinguishable. As soon as an error 
is encountered, the user's buffer is flushed. 



I/O status 

The I/O status request, using a request code (ICODE) of 13, calls the 
RTE operating system to provide information contained in system 
tables. This EXEC call is not a call to the interface driver 
therefore bits 3-7 of ISTATl are not cleared. The LU number of the 
port must be specified in the control word (ICNWD) . One additional 
parameter is required and two more are optional. One, two, or three 
words are returned to the user's program in the parameters passed. 
Table 3-1 lists the I/O status request returns. 

A sample calling sequence for LU 41 is shown below: 



ICODE = 13 
ICNWD =41 
CALL EXE C ( ICODE , I CNWD , I STAl , I STA2 , 1 STA3 ) 



When the call completes, the variables ISTAl, ISTA2, and ISTA3 contain 
the I/O status as shown in Table 3-1. ISTAi is the status word (EQT5) 
and ISTA2 is also a status word (EQT4) . 



3-7 



Table 3-1. I/O Status-Request Returns 



Word 



Bits 



ISTAl 



ISTA2 



ISTA3 



15-14 



13-8 

7-0 
7 
6 
5 
4 
3 



15 
' 14 

13 

12 

11 
10-6 

5-0 



15 
14-5 
4-0 



Description 



I/O controller availability indicator: 

00 = Available for use 

01 = EQT disabled (down) 
10 = Device busy 

Equipment Type code 

Status: 1 = 

Last request timed out 

Break Key hit 

Control D entered on the last request (EOT) 

Reserved for future use, always zero 

Parity error or overflow detected on the last 

request 
Type-ahead data available, control function 6B 

will return the length of type-ahead data in 

the B-Register 
Program schedule enabled 
Reserved for future use, always zero 



Reserved for future use, always zero 

1 = Automatic output buffering enabled 

1 = Driver to process power fail (always 1) 

1 = Driver to process time-out (always 1) 

System communication flag 

Last subchannel addressed 

Select code of the Multiplexer Card 



Logical Unit Status: 

1 = LU down, = LU up 

Reserved for future use, should always be zero 

EQT subchannel associated with the LU number 
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Failure Analysis 

For failure analysis it is important to note that all errors appear as 
time outs, parity or overflow errors. Current HP supplied device 
drivers will not produce the following error message. User written 
device drivers may use the EXIT command described in Chapter 4 to have 
the following error message displayed at the system console. 

I/O XX L #x E #Y S #z 

XX = NR 
TO 
PE 
etc., as specified by device driver 

In the above example x, y, and z are the Logical Unit number, EQT 
number, and subchannel number respectively. If a device is down, any 
I/O control request will wait for the operator to "UP" the EQT number. 

For time-outs it may be that a simple time-out has occurred, 
indicating the operator was too slow in responding to a read request. 
In this case, retry the request. 

If the device is not downed, control will return to the user program 
on error and the user program should be structured to check for errors 
and process accordingly. The "I/O Status" request can be used to 
obtain the status to test for various conditions. 



Read Errors 

If the last command issued was a read, a parity error or data overrun 
may have occurred. Data Overrun indicates the Multiplexer maximum 
throughput rate has been exceeded and data on the LU with the overflow 
bit set was lost. These errors are only detectable on a read 
operation. 
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Chapter 4 
Device Driver Writing 



This chapter explains the writing and use of device drivers that can 
be called by the 12792A Multiplexer interface driver, DVMOO. The 
basic philosophy of using device drivers is explained to give the user 
a better understanding of the steps involved. 



Device Driver/Interface Driver Concept 

An interface driver is a standard RTE driver that converts user EXEC 
requests for input, output, and control into a sequence of assembly 
level instructions which control and pass data to an interface card 
through the I/O backplane of an HP-1000 computer. The interface 




that is called by the interface driver to examine and modify user 
requests. 



Reasons for Device Driver/Interface Driver Use 

The device driver/interface driver concept offers several advantages 
over the conventional monolithic driver. The use of device drivers 
allows flexibility for system designers and users. Many different 
types of equipment may be controlled by a single type of interface as 
long as they are electrically compatible and use the same basic line 
protocol. For example, any RS-232-C (electrical specification) , 
asynchronous (basic line protocol) device may be controlled by the 
12792A interface. Individual device drivers for each of these devices 
may be easily written without knowledge of the I/O card/backplane 
interface. New devices may be added to a system without undertaking 
the monumental task of writing an entirely new driver. The system 
programmer need only write a subroutine to add the required character 
sequences to the user data to control the new device. 
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Differences between devices may be made transparent to user programs. 
Applications programmers need only concern themselves with reading or 
writing data to a "standard" device while the device driver takes care 
of the control needed for the "exotic" device the program is actually 
communicating with. 

Some devices may be customized by using different device drivers for 
different tasks. Printing terminals may be made to look like line 
printers to the user program by writing a device driver to translate 
column one carriage control into the proper escape sequences for the 
terminal. A different device driver may then be used when an 
interactive terminal is desired. These various device drivers may be 
dynamically switched in and out by the user program or by the system 
manager when required. 

A single driver written to control a lajge number of different devices 
through a common type of interface would be very large. Requiring the 
use of this driver would penalize users who only need a few of these 
devices. By using device drivers a system manager need only include 
the driver code needed for the devices on the system, thus saving 
space for other uses. 



Interface Tasks 

To write efficient device drivers it helps to have an understanding of 
the responsibilities of the other components in the I/O interfacing 
subsystem. In the HP 12792A Multiplexer Subsystem the HP 12792A 
interface card is primarily responsible for sending and receiving 
characters on the RS-232-C line and for handling line protocol. When 
enabled to do so, the interface card will handle the ENQ/ACK line 
protocol to prevent terminal buffer over-runs. The interface card 
will transmit and receive the characters to and from the terminal at 
the baud rate for which it has been set by the driver. The interface 
card will automatically pack the eight bit characters into sixteen bit 
data words for efficient DMA transfer to the computer, or unpack the 
sixteen bit words into eight bit bytes for the terminal. The 
interface card will treat the parity bit as described in the Interface 
Support statement in the Multiplexer Configuration Guide, and will 
notify the driver when incorrect parity has been received. 
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Interface Driver Tasks 



Interface Control 

The interface driver (DVMOO) is responsible for controlling the 
interface card via assembly level I/O instructions to the computer I/O 
backplane. The interface driver interprets user requests to properly 
initialize the interface card for baud rate, parity, character length, 
number of stop bits, etc. The interface driver initializes and starts 
DMA transfers between the computer memory and the interface card. 

Operating System Interface 

The interface driver receives EXEC level user requests from the RTE 
operating system and passes them to the device driver for further 
processing. The interface driver processes requests from the device 
driver, returning to the device driver on each request completion. 
The interface driver requests a DMA channel from the RTE operating 
system when a data transfer is required either to send data to the 
card or receive data from the card. When the device driver informs 
the interface driver that the user request is complete, the interface 
driver returns to RTE with the correct device status and transmission 
log or error code in the A and B registers. 



Device Driver Tasl^s 

The device driver is entered on each new user request and on 
completion of each device driver request. The device driver may do 
further checking on request legality. If the device requires a 
special sequence of characters prior to receiving or sending the user 
data, the device driver should format the characters into a buffer and 
send them to the device via a device driver request to the interface 
driver. When the user request is to be processed the device driver 
tells the interface driver to start the request currently in the EQT. 
When the entire request has completed, the device driver places the 
correct status in the EQT and the transmission log in the B register, 
and then informs the interface driver that the request is complete. 
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HP Implementations of Device Drivers 

There are two examples of device driver applications that 
Hewlett-Packard has implemented as part of the HP 12792A Multiplexer 
subsystem. 

Lineprinter Device Driver DDV12 

The device driver DDV12 is used to make HP 2631/2635/7310 printers 
look like typical line printers to user programs. These devices use 
escape sequences and control characters for carriage control while 
standard line printers interpret the first character of each line as a 
carriage control character. The DDV12 device driver examines the 
user's first character and sends the proper control character sequence 
to the printer. The first character is then stripped from the data 
and the data is sent to the printer. The device driver also changes 
the driver type in the EQT to type 12 for linepr inters. 

Block Mode Terminal Device Driver DDV05 

The device driver DDV05 allows utilization of the block mode read 
capabilities of an HP 264X or 262X terminal. The first time a read 
request is made to the terminal its status is read to determine 
whether it is in block or character mode. When a user read request is 
made the device driver first issues a write to the interface driver to 
send a DCl to the terminal. If the terminal is in block mode the 
device driver issues a read to the interface driver and examines the 
first returned character. If the character is a DC2 the device driver 
knows that the terminal is in block mode and trying to send data to 
the interface. A read is then issued for the user buffer length with 
echo and character editing turned off. If the returned character is 
not a DC2, the user program had probably issued a program enabled 
block read (escape lower case d) and the program's data is in the 
buffer just read. 

If the terminal is in character mode, the user's request is executed 
as-is after the DCl is sent (to enable the sof tkeys) . 
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Device Driver Interface 

An uncomplicated device driver/interface driver interface is provided 
making it easy for systems programmers to write their own device 
drivers. All that is required beyond the information given in this 
chapter is a basic familiarity with the flow of I/O requests in RTE 
and a thorough knowledge of the particular device that is being 
communicated with. 



Device Drivers for HP 12792A l\/lultiplexer 

The following points should be kept in mind when writing device 
drivers for the HP 12792A Multiplexer subsystem. First, all read, 
write, and control requests are passed to the device driver by the 
interface driver for modification before they are sent to the 
interface card. The device driver only has to make read, write, or 
control requests to the interface driver; the device driver does not 
issue I/O instructions to the interface card. The device driver 
requests are at the EXEC level, that is, a request word (control word 
as defined for EQT word 6) buffer address and length, or optional 
control request parameters are passed to the interface driver. A 
device driver will typically make several of these requests for each 
user EXEC request. After each device driver request completes the 
interface driver will return to the device driver for the next 
request. It is up to the device driver to tell the interface driver 
when the original user request is complete. The device driver and 
interface driver pass parameters back and forth between each other 
using the A and B registers and the portion of the EQT extent defined 
as the Device Driver EQT Extent. 



Restrictions and Requirements 

When a device driver issues read or write requests the data buffer 
must be either within the device driver or in the same map as the user 
request buffer. If the user request is unbuffered the user request 
buffer is in the user map. If the user request is buffered, class 
I/O, REIO (re-entrant I/O) , or $XSIO (system I/O) the user request 
buffer is in the system map. 
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All requests are passed to the device driver prior to checking by the 
interface driver. Device drivers should check only for control 
requests that are defined for the device driver. Any unrecognized 
control requests should be passed on to the interface driver with a 
command to execute the request. 



System Abort Requests 

A system abort request may be issued to the interface driver at any 
time if the user program currently doing I/O is aborted for any 
reason. The device driver may be entered with the system abort either 
as a new user request or as a continuation request. If the device 
driver is entered as a new user request with the system abort request, 
the device driver should treat it as any unknown control request and 
pass it back to the interface driver. 

However, if the device driver is entered as a continuation with the 
system abort two problems may occur. If the device driver does not 
check for the system abort on a continuation entry and subsequently 
issues a read or write request to the user buffer, the buffer area may 
have been re-allocated for other uses. Program corruption and system 
or subsystem crashes may occur. It is also possible to leave the 
device in an unknown state if an expected user buffer is not written 
to the device. If this is a problem with a device, the device driver 
should check for system abort requests and reset the device to a known 
state. 

In all cases the device driver should check for a system abort request 
prior to issuing an I/O request to the user buffer area. 

To test for a device driver system abort request check the contents of 
EQT word 6 or word 2 of the extent for a 100003 octal ($XSIO control 
zero request) . The above tests are necessary if the device driver 
issues it's own read or write to or from the user buffer area on a 
continuation entry. If the device driver is simply trying to execute 
the user's original request by leaving it in the device driver EQT 
extent word 2, the test for system abort request is not necessary. In 
this case the contents of device driver EQT extent word 2 are changed 
to a control zero at the same time as EQT word 6. 
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Interface Definitions 

Entry to the Device Driver 

On entry to the device driver the following parameter locations are 
defined: 

A register. Bit 15: 1 = initial entry on a new user request 

= continuation entry, signifying a previous 
device driver request is complete 

Bits 14-0: address of device driver EQT extent 
(defined below) 

B register: Previous device driver request transmission log, 
i f any 

The device driver EQT extent words 2-4 are set to the current user 
request definition. These three words are copied from EQT words 
6-8 on each (new or continuation) entry to the device driver. See 
the expanded definitions of the EQT words below. 

Base page locations 1660 through 1672 are the addresses of the 
current EQT words 1 though 11 and base page locations 1771 through 
1774 are the addresses of EQT words 12 through 15. 

On each entry EQT words 4-10 and 14 are defined per the RTE 
definitions (expanded below). EQT words 9 and 10 (READ/WRITE 
optional parameters) are defined per RTE on new request entries 
only (A register bit 15 = 1). However, they are not defined on 
the subsequent continuation entries. If their contents are 
required by the device driver on subsequent entries, they should 
be saved in the device driver EQT extent on the new request entry. 



Return to the Interface Driver 

On return to the interface driver the device driver must insure that 
the proper parameters are passed back to the interface driver. The 
device driver must differentiate between new user request entries and 
continuation entries as the parameters returned to the interface 
driver are different for each case. Also, the device driver must tell 
the interface driver when the original user request is complete and 
set up the correct transmission log and status indications for the 
calling program. 
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On return to the interface driver the following parameter locations 
are defined: 

A register. Bits 15-3: Function modifier 

Bits 2-0: Exit command 

B register: Request timer, or user transmission log 

EQT 5, Bits 7-0: Status for user 

Device driver EQT extent, 

word 1: Physical record length in characters for read 
requests if different from user buffer length 

word 2: Request word as defined for EQT word 6 except 
that bits 15-11 are not defined and should be 
zero 

word 3: Request buffer address 

word 4: Request buffer length (positive number of words 
or negative number of characters) 

Return to Interface Driver — Device Driver EQT Extent 

The physical record length (device driver EQT extent word 1) is used 
to prepare the 12792A interface card for binary data read requests 
where the device does not terminate the record with a special 
character such as carriage return. The physical record length must be 
a positive number of characters. If this parameter is not set it 
defaults to the user buffer length. 

Words 2-4 of the device driver EQT extent may be changed by the device 
driver to cause the interface driver to execute some other request, or 
they may remain unmodified causing the interface driver to perform the 
initial user request. Remember that on each entry words 2-4 of the 
device driver EQT extent are restored to the original user request 
copied from EQT words 6-8. 
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Return to Interface Driver — A-Register 

Exit Command 

On return to the interface driver from the device driver the A 
register bits 2-0 must be set up with the exit command. The exit 
command definition is similar to the RTE definition for the A register 
for a standard driver on return to RTE. The exit command definition 
is as follows: 

Exit command if entered with a new user request 
(A register bit 15 = 1 on entry) 

= start request in device driver extent words 2-4; 

B register = time out value (-lO's ms) 

1 = user I/O request is illegal, give IO07 error 

2 = user control request is illegal, ignore it 

3 = I/O device not ready, down it and print lONR message 

4 = user request completed (immediate completion) ; 

B register = transmission log 

5 = start request (same as 0) 

Exit command if entered after completion of a device driver 
request (A register bit 15 = on entry) 

= user request is complete; B register = transmission log 

1 = I/O device not ready, down it and give lONR message 

2 = end of transmission (EOT) reached, down device and 

give lOET message 

3 = parity error, down device and give lOPE message 

4 = device time out, down device and give lOTO message 

5 = new request in device driver EQT extent words 2-4; 

B register = time out value (-lO's ms) 



Function Modifier 

Error type exit commands (new request 1, 2, and 3 or continuation 
entry 1, 2, 3, and 4) are simply passed to RTE in the A register by 
the interface driver. Action taken (program abort, print error 
message, etc.) is determined by RTE the same as for any standard 
driver. 
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For exit commands that initiate another device driver request (new 
request exit command = or 5, continuation entry exit command = 5) a 
function modifier may be placed in the A register bits 15-3 to 
override and expand the normal request function code contained in the 
device driver EQT extent word 2, bits 10-6. Function modifiers are 
defined for read and write operations. Write function modifiers 
?Mn^?t'' read modification fields and can be used to define the 
function modification for the next read or series of read operations. 
The write function modifier bit fields are defined as follows: 

A register bits 15-3 

Bit 15: end transfer on carriage return (CR) 

14: end transfer on record separator (RS) 

13: end transfer on end of tape (EOT, control D) 

12: end transfer on (DC2) 

11: end transfer on specified character count 

10: enable end on character specified in bits 15-12 

9: enable character editing (backspace, delete, etc) 

8: echo received characters 

7: not defined, should be 

6: not defined, should be 

5: disable ENQ/ACK handshake this transfer only 

4: add CR/LF to buffer if last character is not an 
underline (137 octal) 

3: use write overrides in bits 7-4, if bit 3 is 0, 
bits 7-4 should be 

If bits 7-3 are zero (do not override) the write is configured by bits 
10-6 m the device driver EQT extent word 2. These bits are defined 
as bits 10-6 in EQT word 6 and the ICNWD description in the EXEC write 
section of this manual. 

The read related fields in the write function modifier (bits 15-8) 
will configure the card for any subsequent read operations. This 
eliminates the "window" between writing and reading so that if the 
write triggers a response from the device no data will be lost. 

If enable end on character (bit 10) is set, one or more of bits 15-12 
must be set. Reads will complete on reception of any one of the 
specified characters. If bit 10 is clear, bits 15-12 should be zero. 
If end on count (bit 11) is set, the physical record length in device 
driver EQT extent word 1 should be set to a positive number of 
characters. if bit 11 is set, the end on character bits 15-12 and 10 
are ignored. Only one of bits 10,11 should be set. 
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For read functions the modifier bit fields are defined as follows: 
A register bits 15-8,3 



Bit 15 

14 

13 

12 

11 

10 

9 

8 

7-4 

3 



end transfer on carriage return (CR) 

end transfer on record separator (RS) 

end transfer on end of tape (EOT, control D) 

end transfer on (DC2) 

end transfer on specified character count 

enable end on character specified in bits 15-12 

enable character editing (backspace, delete, etc) 

echo received characters 

reserved for future use, should be zero 

use current card configuration 



If enable end on character (bit 10) is set, one or more of bits 15-12 
must be set. Reads will complete on reception of any one of the 
specified characters. If bit 10 is clear, bits 15-12 should be zero. 
If end on count (bit 11) is set, the physical record length in device 
driver EQT extent word 1 should be set to a positive number of 
characters. 

If bits 15-3 are all zero the read configuration will be determined 
from the control word bits (10-6) in the device driver EQT extent word 
2. These bits are defined as in EQT word 6 and the CONWD described in 
the EXEC read section of this manual. Bit 9 of the EXEC request (EQT 
6) is always used and must be valid. If bit 3 is set bits 15-4 should 
be zero. 



Return to Interface Driver — B-Register 



On return to the interface driver the device dr 
register to be either the transmission log, o 
value. If the initial user request is complete, 
contain the transmission log to be returned^ 
Transmission logs for each device driver operati 
device driver in the B register by the inte 
continuation entry. The device driver may save 
to return, or the device driver may return a 
Convention requires that the transmission log 
either a number of words if the initial user r 
(EQT word 8 is positive) or a number of charact 
initially specified (EQT word 8 is negative). 

If a new device driver request is to be initiated (exit command = 5 on 
continuation, or 5 or on initial entry) the ?, ^^^^i^^^'^^^^^^^l^^ 
contain the request time out value. This value will be a negative 
number of time base ticks (lO's of milliseconds). If the ^ ^^^i.^^ 
driver needs to use the system defined time out for the device, EQT 
word 14 should be copied into the B register. 



iver should set the B 
r the device time out 

the B register should 
to the user program, 
on are returned to the 
rface driver on each 

one or more of these 
ny meaningful number, 
be a positive number, 
equest specified words 
ers if characters were 



4-11 



Return to Interface Driver — EQT Entries 

As a general rule it is not advisable for the device driver to modify 
the EQT, except for the area defined as the device driver EQT extent 
However some EQT areas are routinely modified by device drivers. In 
EQT word b the equipment type (bits 13-8) should be modified on the 
first entry to a device driver to reflect the device type the device 
driver is emulating. On each completion exit (new request exit 
command = 4, or continuation entry exit command = 0) the status field 
in EQTword 5 bits 7-0 should be updated to return status to the user. 
This field should be the same as is defined for the device type the 
device driver is emulating. 

After the user's request has been processed, if further interaction 
with the interface driver is required EQT words 7 and 8 are available 
as convenient temporary storage areas. It is common to store the 
transmission log in EQT word 8 in these cases. Words 9 and 10 are 
used by the interface driver for temporary storage and should not be 
modified by the device driver. 



Selected EQT Definitions and Uses 

EQT Word 4 — Subchannel 

EQT word 4 bits 10-6 contain the currently addressed subchannel. This 
information is required by device drivers that perform different tasks 
for different subchannels. 

EQT Word 5 — Equipment Type Code and Status 

EQT word 5 bits 13-8 contain the equipment type code as specified by 
the driver name at generation. The 12792A Multiplexer interface 
driver is DVMOO so the type code is 00. Device drivers that emulate 
devices should use a type code that corresponds to the device they are 
emulating. On first entry the device driver should change the tvpe 
code in the EQT table. The following is a list of type codes and 
devices they represent: 
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00 to 07 = terminals or paper tape devices 

00 = teleprinter or keyboard control device 

01 = photoreader 

02 = paper tape punch 

05 = intelligent terminal devices generally having block 

mode capability (HP 264x and 262x terminals) 
07 = multipoint devices 
10 to 17 = other unit record devices 

10 = plotters (Calcomp or HP 7210) 

11 = card readers 

12 = line printers 

13 = TV monitor 

15 = mark sense card readers 
20 to 35 = mag tape or mass storage devices 

23 = 9 track mag tape 

24 = 7 track mag tape 

30 = fixed head disc 

31 = 7900 moving head disc 

32 = 7905/6/20/25 moving head disc 

33 = flexible disc drives 

36 = writable control store (microcode execution space) 

37 = HPIB Interface 

47 = Multidrop FDL interface 

EQT word 5 bits 7-0 contain the device status of the 12792A 
Multiplexer on each entry to the device driver. This status is 
defined as follows: 

Bit 7 Time out, if the driver was entered on a time out 

this bit will be set on entry to the device driver. 
6 Break, if the 12792A Multiplexer card received a break 

character from the terminal during the last operation 

this bit will be set. 
5 EOT, The End Of Tape bit will be set if an EOT 

(004 octal) was received during the last read. 
4 Bit 4 is not currently used 
3 PE/OV, the Parity Error/Overflow bit will be set 

if either one of these conditions occurred on the 

last read. 
2 Type-ahead data, this bit will be set if type-ahead 

data is available on the card. 
1 Schedule, this bit indicates that program scheduling 

on unsolicited interrupt has been enabled (interface 

driver control function 20) 
Bit is not currently used 

The above definitions apply whenever the device driver is entered from 
the interface driver. The device driver is free to change any of the 
status bits if emulation of other driver types is desired. On a user 
request complete exit from the device driver the status bits (EQT word 
5) will be passed to the user program in the A register. 
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EQT word 6 and device driver EQT extent word 2 contain the current 
request word which is defined as follows: 

Bits 15-14 Request type: 

00 = standard user request 

01 = automatic buffered user request (request 

buffer is in system available memory) 

10 = a system request ($XSIO) 

11 = user Class I/O request (request buffer is 

in system available memory) 

Bits 15-14 are only defined in EQT word 6. They are undefined 
in the device driver EQT extent word 2 and should be set to 
zero if the device driver modifies this word. 

Bit 12 Z-bit indicates a second buffer is available 

on a read or write. If set, EQT word 9 contains 
the address of the buffer and EQT word 10 
contains the length. If the Z-bit is clear, 
EQT words 9 and 10 contain 1 word optional 
parameters. 

In the 12792A Multiplexer subsystem, the interface driver 
does not use the double buffering feature, it is therefore 
available to the device driver for use. 

Bits 10-6 Subfunction, as defined in the EXEC request 
section of this manual for the EXEC control 
word. 

Bits 1-0 Function: 

01 = read request 

10 = write request 

11 = control request 

Bits 13,11 These bits are undefined and should be set to 
and zero if the device driver modifies the request 
5-2 in the device driver EQT extent word 2. 

EQT word 7 and device driver EQT extent word 3 is the user buffer 
address. The interface/device driver is always entered in the same 
map as the user buffer, so the user buffer address is in the current 
map. 

EQT word 8 and device driver EQT extent word 4 is the user buffer 
length. The length is either a positive number of words, or a 
negative number of characters. 
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EQT word 9 is an optional parameter. If the Z-bit (EQT word 6 bit 12) 
is set EQT word 9 is the address of a secondary user buffer which is 
in the same map as the primary user buffer. If the Z-bit is clear EQT 
word 9 contains the optional parameter or zero if no parameter was 
passed. 

EQT word 10 is an optional parameter. If the Z-bit is set _ EQT word 10 
is the length of the secondary user buffer. It is a positive number 
of words, or a negative number of characters. If the Z-bit is clear, 
EQT word 10 contains the second optional parameter, or zero if a 
second optional parameter was not passed. 

Both EQT words 9 and 10 are only available to the device driver on a 
new request entry. These words must be saved in the device driver EQT 
extent if they are required later by the device driver. 

EQT word 14 contains the system defined time-out reset value for the 
device, a negative number of time base ticks (10' s of ms) . This value 
is set by the system at generation, or by the system TO command, or by 
the interface driver by a control 22 request. This word may also be 
set directly by the device driver if desired. 

EQT word 15 contains the time out clock count down counter. This word 
is setup by the interface driver prior to returning to the system. 
This word should not be modified by the device driver. On any device 
driver request to the interface driver the time out count for EQT 15 
should be passed in the B register. The value should be a negative 
number of lO's of milliseconds. If the system defined time out is to 
be used, the device driver must pass the contents of EQT word 14 to 
the interface driver in the B register. 



Device Driver Address Table 

The interface driver uses a device driver address table to find the 
correct device driver when the device driver is selected with^ a 
control 33 request. The device drivers are selected by numbers which 
are determined by their positions in the device driver address table. 
Each device driver to be used with the interface driver must have an 
entry in the device driver address table. To add device drivers to 
the device driver address table, the user must create his own table. 
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The device driver address table should have the following format: 

NAM $DVTB,8 DEVICE DRIVER ADDRESS TABLE 
ENT $DVTB 

EXT DVNMl,... ,DVNMn 
* 

* DEVICE DRIVER ADDRESS TABLE 
* 

$DVTB DEC n NUMBER OF ENTRIES IN TABLE 

DEF DVNMl+0 ADDRESS OF DEVICE DRIVER 2 
DEF +0 3 



DEF DVNMn+0 
END 



ADDRESS OF DEVICE DRIVER n+1 



The names of the device drivers may be any valid label, as long as 
they do not conflict with any other symbol in the system. Note that 
the first device driver in the table is selected by a control 33 
request to use device driver number two. This is because the the 
value zero is reserved for "no change", and one is the used for the 
default device driver. Since the device driver number field is 4 bits 
wide, the user is able to include the default and up to 14 other 
device drivers in the system. 



Location and Size of Device Drivers 



Since the device driver address table and device drivers themselves 
are called directly by the interface driver, they must be resident 
within the same map. This poses a few restrictions on the number and 
location of these modules. 

The interface driver requires approximately 1400 words of memory, so 
up to 600 words are left in a standard two page driver partition for 
the device driver address table and the device drivers. If this is 
not enough room either the driver partition can be changed to three or 
more pages, or one or more device drivers and the table may be 
relocated into Table Area I. If $DVTB is relocated into Table Area I, 
all device drivers will be forced to Table Area I. The disadvantages 
are that the user available space in the system is reduced. If the 
driver partition size is increased, the size of the largest available 
user partition is reduced by an equal amount, and the size change must 
be an incremental number of pages. If the modules are relocated in 
Table Area I, the actual space used may not take away from user space 
unless a page boundary is crossed, in which case a page will be taken 
away from the largest available user partition. Device drivers 
relocated m Table Area I will take space otherwise used as System 
Available Memory. In the RTE-IVB operating system, only these two 
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methods of gaining space for device drivers will guarantee that the 
device driver and interface driver will be in the same map and be 
mapped properly to handle all user requests. The interface driver and 
device drivers and table could be all relocated into the system driver 
area (SDA) . More space is available to users, but large background 
programs will not be able to make unbuffered requests to the driver. 

In RTE-M the device drivers and device driver table are simply 
relocated as system modules along with the interface driver. 



Case Study: A Device Driver Writing Example 

The following is an example of device driver writing that illustrates 
some of the problems, solutions, and steps involved in writing a 
typical device driver. The device driver in this example is written 
to make a terminal look like two separate terminals, sharing the 
keyboard, and splitting the screen into two separate areas. 



Task Definition 

The tasks involved in interfacing with a device using a device driver 
should be clearly defined and broken down into a sequence of logical 
steps. In this example the object is to make an HP 26XX terminal 
appear as two terminals for read and write requests. Requests made to 
an LU defined as an EQT subchannel will go to the left half of the 
terminal display, and requests to subchannel 1 will go to the right 
half of the display. 

Three major tasks are defined for the device driver while the 
interface driver handles the user's actual read or write request. The 
three tasks all involve sending specific character sequences to the 
terminal for initialization in a classic device driver application. 

Margin Set Up 

The first task is to set the left and right margins on the terminal to 
keep the following text on the respective side of the screen. Upon 
determination of the subchannel for each new user request the device 
driver sends the escape sequence to set the left and right margin at 
predetermined columns on the terminal screen. Due to terminal 
idiosyncrasies the left margin must be set first for subchannel 

(left side) and the right margin must be set first for subchannel 1 

(right side) . 
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Cursor Position 

The second major task is to position the cursor so that the subsequent 
read or write operations will appear at the correct place on the 
screen. The escape sequence to position the cursor is formatted with 
the correct cursor position for the left or right side of the screen. 
The device driver keeps track of the current cursor position for each 
side in the device driver EQT extent. Once the request buffer is 
formatted with the correct cursor position the device driver passes it 
to the interface driver as a device driver request. 

Cursor Traclcing 

The third major task for the device driver is to find out where the 
user's request has left the cursor for the side of the screen that was 
3ust addressed. To do this the device driver writes a request for a 
cursor position sense to the terminal and then reads back the result. 
The resulting cursor position is separated from the escape sequence 
that precedes it and stored away in the device driver EQT extent for 
the subchannel that is addressed. 

l\/linor Taslcs 

Additionally, in an effort to reduce overhead, the device driver is 
written to not set the margins or position the cursor when the 
subchannel addressed is the same as the previous subchannel. It is 
assumed that the cursor and margins will remain in position between 
sequential requests to the subchannel. In order to implement this 
step the device driver saves the last addressed subchannel in the 
device driver EQT extent. 

Finally the device driver patches the equipment type code into EQT 
word 5. This patch will take place only the first time the device 
driver is accessed for any particular EQT. Since either subchannel 
most closely resembled type 00 devices to the user the equipment type 
used is 00. This step is included for illustration only. When any 
"Select New Device Driver" request is made (CN,LU, 30B ,XXXXXn where 
bits 3-0 = 0) the driver is reset to 00. 
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Device Driver Operation 

Functionally the device driver makes a series of tests on each entry 
to determine the action required. Processing a user request is a 
sequence of actions that generally fall in the following order: 

1. Position left or right margin 

2. Set margin 

3. Position other margin 

4. Set margin 

5. Position cursor 

6. Perform user request 

7. Request cursor position 

8. Read cursor position 

9. Save cursor position 

Each action is handled by a separate routine that saves the address of 
the next routine in the device driver EQT extent so that execution 
moves in a step by step fashion on each continuation entry to the 
device driver. 

Operation Flow 

Figure 4-1 shows the complete device driver flowchart. 
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Figure 4-1. Device Driver Flow Chart 
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Figure 4-1 (cont'd) . Device Driver Flow Chart 
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Set Up Device Driver EQT Extent Pointers 



On each entry to the device driver the device driver EQT extent 
addresses are stored into a table in the device driver. On each entry 
the A register contains the first device driver EQT extent address and 
bit 15 indicates new or continuation entry. Bit 15 is saved for later 
testing and stripped from the address before the addresses of the 
device driver extent are saved. 



DDSOO NOP DEVICE DRIVER ENTRY POINT 

STB TEMP SAVE B TEMPORARILY 

CLE SAVE A[15] 

ELA,RAR AND CLEAR IT 

LDB DEXAD ADDRESS OF TABLE 

LDX DM15 DECIMAL MINUS 15 



* CREATE TABLE OF DD EXTENT ADDRESSES 

DEXLP STA B,I 

INA 
INB 

ISX 

JMP DEXLP 



A CONTAINS ADDRESS OF DD EXTENT WORD 

B CONTAINS ADDRESS IN TABLE 
X CONTAINS COUNT DOWN 



DEXAD DEF DEXOl 
DEXOl NOP 
DEX02 NOP 



ADDRESS OF TABLE 

ADDRESS OF FIRST DD EXTENT WORD 



DEX15 NOP 



ADDRESS OF DD EXTENT WORD 15 



After the initial setup is done on each entry the device driver then 
teststhe bit that indicates a new request entry that was saved in the 
E register. Continuation entries go the next routine to be executed 
whose address is always saved in the device driver EQT extent word 13. 
If it is not a continuation entry the device driver tests to see if it 
is the first ever entry for the EQT. Device driver EQT extension word 
15 contains an ASCII "SO" if this is not the first ever entry. 
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EQT Setup on First Entry 



On the first entry for any EQT the starting cursor positions for the 
left and right sides of the screen are established. The cursor 
positions are stored in ASCII format in the device driver EQT extent 
words 5 - 12. The starting positions, upper left corner of each 
screen, are hard coded in ASCII in the driver. 



LDA ASO 
STA DEX15,I 

JSB .CFER 

DEF DEX05,I 

DEF SORC 

JSB .CFER 

DEF DEX09,I 

DEF SIRC 

LDA EQT5,I 
AND TMASK 
STA EQT5,I 



GET THE ASCII "SO" 

SAVE IT TO INDICATE NOT FIRST ACCESS 

MOVE FOUR WORDS OF CURSOR POSITION 

TO THE DD EXTENT 

FROM THE DEFINITION LOCATION 

MOVE FOUR WORDS FOR THE OTHER CURSOR 

TO THE DD EXTENT 

FROM THE DEFINITION LOCATION 

GET THE EQT ENTRY WITH EQUIP TYPE 
(14037B) MAKE THE TYPE 00 
SAVE IT 



EQT5 EQU 1644B 
SORC ASC 4,000r000C 
SIRC ASC 4,000r042C 

Subchannel Determination 



STARTING ROW & COLUMN SUBCHANNEL 
STARTING ROW & COLUMN SUBCHANNEL 1 



On a new request entry the device driver determines what subchannel 
the request is addressed to. The subchannel is in the EQT word 4 bits 
10-6. The subroutine GTSCH gets the subchannel and returns it in the 
A register. 



GTSCH NOP 

LDA EQT4,I 
AND B3.7K 
ALF,ALF 
RAL,RAL 
JMP GTSCH, I 



GET FROM EQT WORD 4 
(3700B) ONLY LOOK AT THE SUBCHANNEL BITS 

POSITION TO RIGHT 
RETURN 



EQT4 EQU 1663B 

Once the subchannel has been determined the device driver must save it 
in the device driver EQT extent and then go set the left or right 
margin. Note that although the driver specifies subchannel or 1 it 
will use any even subchannel as the left side or any odd subchannel as 
the right side. 
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JSB GTSCH 

STA DEX14,I 

SLA 

JMP RMPOS,I 

JMP LMPOS,I 



GO GET THE SUBCHANNEL FROM THE EQT 

SAVE IT IN DD EXTENT WORD 14 

ODD OR EVEN? 

ODD — DO RIGHT FIRST 

EVEN — DO LEFT FIRST 



Output a Setup String to the Terminal 



The device driver routines to output various strings of characters to 
set up the terminal are all basically the same. They all set up the 
request in device driver EQT extent words 2-4 and exit through a 
common return routine. Device driver extent word 2 is set up with a 
read or write request code, word 3 with a buffer address inside the 
device driver, and word 4 is set up with the buffer length. 



* POSITION CURSOR FOR LEFT MARGIN SET 
* 



LMPOS 


DEF 


* + l 




LDA 


BNWT 




STA 


DEX02,I 




LDB 


DEX14,I 




LDA 


LMPA 




SLB 






INA 






LDA 


A, I 




STA 


DEX03,I 




LDA 


CMLNG 




STA 


DEX04,I 




LDB 


LMSET 




LDA 


MODXl 




JMP 


CRTN 


BNWT 


OCT 


000102 


LMPA 


DEF 


LMPAD 


LMPAD 


DEF 


LMPAO 




DEF 


LMPAl 


LMPAO 


OCT 


15446 




ASC 


3, OOOC 


LMPAl 


OCT 


15446 




ASC 


3, 042C 


CMLNG 


DEC 


4 


MODXl 


OCT 


102005 


* 







ADDRESS OF ROUTINE 

GET THE CONTROL WORD FOR WRITE W/0 CRLF 

PUT INTO DD EXTENT 

GET THE SUBCHANNEL NUMBER 

GET THE LEFT MARGIN POSITION ADDRESS POINTER 

TEST ON SUBCHANNEL 

ODD — USE THE OTHER ONE 

GET THE ADDRESS OF THE CHARACTER STRING 

PUT INTO DD EXTENT 

GET THE CURSOR MOVE LENGTH WORD 

PUT INTO DD EXTENT 

GET THE ADDRESS OF THE NEXT ROUTINE 

GET THE WRITE MODIFIER/EXIT COMMAND 

GO TO THE COMMON RETURN ROUTINE 



CONTROL WORD FOR WRITE W/0 CRLF 
ADDRESS OF LEFT MARGIN POSITION TABLE 
EVEN SUBCHANNEL POSITION ADDRESS 
ODD SUBCHANNEL POSITION ADDRESS 
ASCII "ESC &" 

COLUMN POSITION FOR LEFT SIDE LEFT MARGIN 
ASCII "ESC &" 

COLUMN POSITION FOR RIGHT SIDE LEFT MARGIN 

WRITE MODIFIER/EXIT COMMAND: 

DO REQUEST IN DEX0 2-4, END NEXT READ ON CR 

DO NOT MODIFY WRITE IN DEX02 
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The common return routine is used by all of the device driver routines 
that initiate their own requests to the interface driver. The return 
routine expects the address of the next routine to be in the B 
register and the modifier/exit command to already be in the A 
register. The return routine saves the next address in the device 
driver EQT extent word 13 and picks up the time out value used for all 
setup requests. 

CRTN STB DEX13,I SAVE NEXT ROUTINE ADDRESS IN DD EXT WORD 13 
LDB TO GET TIME OUT FOR SETUP REQUESTS 
JMP DDSOO,I RETURN TO INTERFACE DRIVER 

Stepping from one routine to the next is made simple by always saving 
the next routine address in device driver EQT extent word 13. On any 
continuation entry the device driver only has to jump through the 
contents of extent word 13 indirect. 

DDSOO NOP DEVICE DRIVER ENTRY POINT 

STB TEMP SAVE B TEMPORARILY 
CLE 

ELA,RAR SAVE A[15] FOR CONTINUATION TEST 

SET UP DD EXTENT ADDRESSES 

LDB TEMP RESTORE B 

SEZ,RSS TEST FOR CONTINUATION 

JMP CSOO IF E (WAS A[15]) IS SET, GO TO CONTINUATION 

CSOO LDA DEX13rI GET NEXT ROUTINE ADDRESS 
JMP A, I GO DO IT 



Perform the Original User Request 

Since the original user request is restored to the device driver EQT 
extent words 2-4 on each entry to the device driver, processing the 
original request is quite simple. Before returning to the interface 
driver, the device driver only puts the system defined time out value 
in the B register and an exit command = 5 in the A register. In this 
device driver the next routine address is also saved in the device 
driver EQT extent word 13 to keep the flow of requests going. 
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DORQ DEF * + l 

LDB EQT14,I 
LDA SENCU 
STA DEX13,I 
LDA M0DX2 
JMP DDSOO,I 



ADDRESS OF ROUTINE 

GET THE SYSTEM TIME OUT WORD 

GET THE NEXT ROUTINE ADDRESS 

SAVE IT FOR RETURN 

GET THE MODIFIER/EXIT COMMAND 

RETURN DIRECTLY TO THE INTERFACE DRIVER 



M0DX2 OCT 000005 
* 

EQT14 EQU 1773B 



UNIVERSAL DON'T MODIFY ANYTHING/DO REQUEST 
IN THE DD EXT MODIFIER/EXIT COMMAND 



Since further requests to the interface driver are required after 
completion of the original user request, the device driver must save 
the transmission log from the user request. This is accomplished by 
storing the contents of the B register in EQT word 8, which was the 
original user request length (in characters) . 

Read Cursor Position 

SENCU senses where the cursor was left at the end of the user request. 
An escape - lower case a - DCl (binary write) is sent to the terminal, 
requesting the terminal to send back the cursor position. The card is 
pre-conf igured for the next read by setting the high order bits in 
MODXl. This demonstrates the read modifier on a write request. 



SENCU DEF *+l 

STB EQT8,I 
LDA BNWT 
STA DEX02,I 
LDA SENCA 
STA DEX03,I 
LDA SENSL 
STA DEX04,I 
LDA MODXl 
LDB RDCUS 
JMP CRTN 



ADDRESS OF THE ROUTINE 

SAVE TRANSMISSION LOG IN EQT 8 

SET UP BINARY WRITE 

IN DEVICE DRIVER EQT EXT 

GET ADDRESS OF CURSOR SENSE 

FOR DD EQT EXT 

GET LENGTH FOR SENSE COMMAND 

PUT IT IN THE DD EQT EXT 

WRITE MODIFIER/EXIT COMMAND 

GET THE ADDRESS OF NEXT 

RETURN TO INTERFACE DRIVER 
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Final Completion Return to the Interface Driver 



Completion is signified on return to the interface driver by a zero in 
the A register and the user request transmission log in the B 
register. 



LDB EQT8,I 

CLA 

JMP DDSOO,I 



RETRIEVE TRANSMISSION LOG 
SET COMPLETION EXIT COMMAND 
RETURN TO INTERFACE DRIVER 



EQT8 EQU 1667B 

Device Driver Address Table 

The following device driver address table is required to include the 
device driver with the interface driver at generation time. 



ASMB,Q 



NAM $DVTB,8 DEVICE DRIVER ADDRESS TABLE 
ENT $DVTB 
EXT DDSOO 



* DEVICE DRIVER ADDRESS TABLE 
* 

$DVTB DEC 1 NUMBER OF ENTRIES IN TABLE 

DEF DDSOO+0 ADDRESS OF DEVICE DRIVER 2 
END 

The device driver is then selected via a control 33, 000002 request to 
the interface on either the subchannel or 1 LU. 



Sample Device Driver Listing 

The following sample device driver is given to illustrate the various 
procedures involved in interfacing to the 12792A Multiplexer Interface 
Driver (DVMOO) . It is intended as an example only and is not a 
supported functioning product. 
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0001 

0002* 

0003* 

0004* 

0005* 

0006* 

0007* 

0008* 

0009* 

0010* 

0011 

0012 

0013 
0014* 

0015 

0016 

0017 

0018 

0019 

0020 

0021* 

0022 

0023 

0024 

0025 

0026 

0027 

0028 

0029 

0030 

0031 

0032 

0033 

0034 

0035 

0036 

0037 

0038* 

0039* 

0040* 

0041 

0042 

0043 

0044 

0045 

0046 

0047 
0048 
0049 
0050 



ASMB,Q 

MULTIPLEXER DEVICE DRIVER FOR SPLIT SCREEN OPERATION OF 
A 264X TERMINAL. LEFT HALF OF SCREEN IS SUBCHANNEL 0, 
RIGHT HALF IS SUBCHANNEL 1. FUNCTION IS OTHERWISE DVMOO. 
THIS DEVICE DRIVER WILL SET THE MARGINS FOR LEFT OR RIGHT 
HALF OPERATION AND POSITION THE CURSOR TO IT'S LAST KNOWN 
POSITION IN THE APPROPRIATE HALF OF THE SCREEN ACCORDING 
TO THE SUBCHANNEL ADDRESSED ON EACH OPERATION. 



00000 



00000 
00001 
01663 
01664 
01667 
01773 

00000 
00001 
00002 
00003 
00004 
00005 
00006 
00007 
00010 
00011 
00012 
00013 
00014 
00015 
00016 
00017 



NAM DDS00,8 SPLIT SCREEN DEVICE DRIVER 
ENT DDSOO 
EXT .CFER 



A EQU 

B EQU 1 

EQT4 EQU 1663B 

EQT5 EQU 1664B 

EQT8 EQU 1667B 

EQT14 EQU 1773B 



OOOOOIR 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 

000000 



DEXAD 
DEXOl 
DEX02 
DEX03 
DEX04 
DEX05 
DEX06 
DEX07 
DEX08 
DEX09 
DEXIO 
DEXll 
DEX12 
DEX13 
DEX14 
DEX15 



DEF DEXOl 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 

NOP 



SETUP ON EACH ENTRY 



00020 
00021 
00022 
00023 
00024 
00025 
00026 
00027 
00030 
00031 
00032 



000000 

000313R 

000040 

001623 

OOOOOOR 

105745 

000267R 

000001 

002004 

006004 

105760 



DDSOO 



DEXLP 



NOP 




STB 


TEMP 


CLE 




ELA, 


rRAR 


LDB 


DEXAD 


LDX 


DM15 


STA 


B,I 


INA 




INB 




ISX 





CURRENT SUB CH 

M 



PHYSICAL RECORD LENGTH 

EQT6 COPY 

EQT7 COPY 

EQT8 COPY 

CURRENT SUB CH ROW WORD 1 

WORD 2 
CURRENT SUB CH COL WORD 1 

WORD 2 
ROW WORD 1 

WORD 2 
CURRENT SUB CH 1 COL WORD 1 

" WORD 2 

NEXT ROUTINE ADDRESS 
CURRENT (LAST) SUBCHANNEL 
FIRST ACCESS FLAG = ASCII SO 



SAVE B TEMPORARILY 

SAVE A [15] FOR CONTINUE TEST 
SAVE EXTENT ADDRESSES 



A = ADDRESS OF DD EQT EXT 1 
B = ADDRESS OF DEXOl 
DO FOR DEXOl-15, ADDRESSES 
OF DEVICE DD EXT WORDS 1-15 



4-28 



0051 

0052* 

0053 

0054 

0055 

0056* 

0057* 

0058* 

0059 

0060 

0061 

0062* 

0063 

0064 

0065* 

0066 

0067 

0068 

0069 

0070 

0071 

0072* 

0073 

0074 

0075 

0076* 

0077* 

0078* 

0079* 

0080 

0081 

0082 

0083 

0084 

0085* 

0086* 

0087* 

0088 

0089 

0090 

0091 

0092 

0093 

0094 

0095 

0096 

0097 

0098 

0099 

0100 

0101 



00033 000027R 

00034 000313R 

00035 002041 

00036 000254R 



JMP DEXLP 

LDB TEMP 
SEZ,RSS 
JMP CSOO 



RESTORE B 

TEST FOR CONTINUATION 

GO DO CONTINUATION 



SPECIAL PROCESSING TO SETUP EQT ON FIRST ACCESS 



00037 000017R 

00040 000277R 

00041 000250R 

00042 000277R 

00043 000017R 

00044 OOOOOIX 

00045 100005R 

00046 000300R 

00047 OOOOOIX 

00050 lOOOllR 

00051 O00304R 

00052 001664 

00053 000276R 

00054 001664 



LDA DEX15,I 

CPA ASO 
JMP SUBCK 

LDA ASO 
STA DEX15,I 

JSB .CFER 
DEF DEX05,I 
DEF SORC 
JSB .CFER 
DEF DEX09,I 
DEF SIRC 

LDA EQT5,I 
AND TMASK 
STA EQT5,I 



GET FIRST ACCESS FLAG 

CONTAINS ASCII "SO" 
NOT FIRST ACCESS, CHECK 



SUBCH 



FIRST ACCESS, SET UP FLAG 



SET UP SUB CH ROW AND COL 



SET UP SUB CH 1 ROW AND COL 



SET UP DRIVER TYPE 



GET THE SUBCH AND DECIDE THE PATH (SUB SET LEFT MARGIN FIRST, 
SUB 1 SET RIGHT MARGIN FIRST) 



00055 000261R JSB GTSCH 

00056 000016R SVSCH STA DEX14,I 

00057 000010 SLA 

00060 000117R JMP RMPOS,I 

00061 000062R JMP LMPOS,I 

POSITION FOR LEFT MARGIN SET 



00062 000063R LMPOS DEF 

00063 000310R LDA 

00064 000002R STA 

00065 000016R LDB 

00066 000330R LDA 

00067 004010 SLB 

00070 002004 INA 

00071 000000 LDA 

00072 000003R STA 

00073 000272R LDA 

00074 000004R STA 

00075 OOOIOOR LDB 

00076 000314R LDA 

00077 000256R JMP 



* + l 

BNWT 

DEX02,I 

DEX14,I 

LMPA 



A, I 

DEX03,I 

CMLNG 

DEX04,I 

LMSET 

MODXl 

CRTN 



GO GET SUBCHANNEL 

AND SAVE 

ODD SUBCHANNEL? 

YES, DO RIGHT MARGIN FIRST 

NO, DO LEFT MARGIN FIRST 



ADDRESS OF ROUTINE 

SET UP BINARY WRITE 

TO POSITION THE CURSOR 

GET SUBCHANNEL 

GET LEFT MARGIN POINTER 

ODD SUBCH USE THE OTHER ONE 

GET THE ADDRESS 
PUT IT IN THE DD EXTENT 
GET CURSOR MOVE LENGTH WORD 
PUT IT IN THE DD EXTENT 
GET L. MARGIN SET ADDRESS 
WRITE MODIFIER/EXIT COMMAND 
RETURN TO INTERFACE DRIVER 
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0102* 

0103* 

0104* 

0105 

0106 

0107 

0108 

0109 

0110 

0111 

0112 

0113 

0114 

0115 

0116 

0117 

0118 

0119 

0120* 

0121* 

0122* 

0123 

0124 

0125 

0126 

0127 

0128 

0129 

0130 

0131 

0132 

0133 

0134 

0135 

0136 

0137* 

0138* 

0139* 

0140 

0141 

0142 

0143 

0144 

0145 

0146 

0147 

0148 

0149 

0150 

0151 

0152 



SET THE LEFT MARGIN 



00100 
00101 
00102 
00103 
00104 
00105 
00106 
00107 
00110 
00111 
00112 
00113 
00114 
00115 
00116 



OOOIOIR 

000310R 

000002R 

000332R 

000003R 

000271R 

000004R 

000016R 

000010 

000114R 

000117R 

002001 

000154R 

000314R 

000256R 



LMSET DEF 
LDA 
STA 
LDA 
STA 
LDA 
STA 
LDA 
SLA 
JMP 
LDB 
RSS 
LDB 
LDA 
JMP 



*+l ADDRESS OF ROUTINE 

BNWT SET UP BINARY WRITE 

DEX02,I IN DEVICE DRIVER EQT EXT 

LMSTA GET ADDRESS OF L. MARGIN SET 

DEX03,I FOR DD EQT EXT 

MSLNG GET LENGTH FOR MARGIN SET 

DEX04,I PUT IT IN THE DD EQT EXT 

DEX14,I GET SUBCHANNEL 

ODD? 

*+3 YES, GO POSITION CURSOR 

RMPOS NO, GET RIGHT MARGIN ADDRESS 

CUPOS GET CURSOR POSITION ADDRESS 

MODXl WRITE MODIFIER/EXIT COMMAND 

CRTN RETURN TO INTERFACE DRIVER 



POSITION CURSOR FOR RIGHT MARGIN SET 

00117 000120R RMPOS DEF *+l ADDRESS OF ROUTINE 

00120 000310R LDA BNWT SET UP BINARY WRITE 

00121 000002R STA DEX02,I TO POSITION THE CURSOR 

00122 000016R LDB DEX14,I GET SUBCHANNEL 

00123 000345R LDA RMPA GET R. MARGIN ADDRESS POINTER 

00124 004010 SLB ODD SUBCH USE THE OTHER ONE 

00125 002004 INA 

00126 000000 LDA A, I GET THE ADDRESS 

00127 000003R STA DEX03,I PUT IT IN THE DD EXTENT 

00130 000272R LDA CMLNG GET CURSOR MOVE LENGTH WORD 

00131 000004R STA DEX04,I PUT IT IN THE DD EXTENT 

00132 000135R LDB RMSET GET R. MARGIN SET ADDR 

00133 000314R LDA MODXl GET WRITE MODIFIER/EXIT 

00134 000256R JMP CRTN RETURN TO INTERFACE DRIVER 

SET THE RIGHT MARGIN 

00135 000136R RMSET DEF *+l ADDRESS OF ROUTINE 

00136 000310R LDA BNWT SET UP BINARY WRITE 

00137 000002R STA DEX02,I IN DEVICE DRIVER EQT EXT 

00140 000347R LDA RMSTA GET ADDRESS OF R. MARGIN SET 

00141 000003R STA DEX03,I FOR DD EQT EXT 

00142 000271R LDA MSLNG GET LENGTH FOR MARGIN SET 

00143 000004R STA DEX04,I PUT IT IN THE DD EQT EXT 

00144 000016R LDA DEX14,I GET THE SUBCHANNEL 

00145 000010 SLA ODD? 

00146 000151R JMP *+3 YES, GO SET LEFT MARGIN 

00147 000154R LDB CUPOS NO, GET CURSOR POS . ADDRESS 

00150 002001 RSS 

00151 000062R LDB LMPOS GET L. MARGIN POS. ADDRESS 
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0153 

0154 

0155* 

0156* 

0157* 

0158 

0159 

0160 

0161 

0162 

0163 

0164 

0165 

0166 

0167 



0168 

0169 

0170 

0171 

0172 

0173 

0174 

0175* 

0176* 

0177* 

0178 

0179 

0180 

0181 

0182 

0183 

0184* 

0185* 

0186* 

0187 

0188 

0189 

0190 

0191 

0192 

0193 

0194 

0195 

0196 

0197 

0198* 

0199* 

0200* 

0201 



00152 000314R 

00153 000256R 



LDA MODXl WRITE MODIFIER/EXIT COMMAND 
JMP CRTN RETURN TO INTERFACE DRIVER 



POSITION CURSOR FOR OPERATION ON A SUBCHANNEL 



00154 000155R CUPOS 

00155 000310R 

00156 000002R 

00157 000016R 

00160 000360R 

00161 004010 

00162 002004 

00163 000000 

00164 000361R 

00165 105777 

00166 000272R 

00167 000000 

00170 000362R 

00171 000003R 

00172 000273R 

00173 000004R 

00174 000177R 

00175 000314R 

00176 000256R 



DEF *+l 
LDA BNWT 
STA DEX02,I 
LDB DEX14,I 
LDA CPAD 
SLB 
INA 

LDA A, I 
LDB CPVAD 
MVW D4 



LDA CPBFA 
STA DEX03,I 
LDA CPLNG 
STA DEX04,I 
LDB DORQ 
LDA MODXl 
JMP CRTN 



DO THE ORIGINAL USER REQUEST 
00177 000200R DORQ DEF *+l 



00200 001773 

00201 000205R 

00202 000015R 

00203 000315R 

00204 000020R 



LDB EQT14,I 
LDA SENCU 
STA DEX13,I 
LDA M0DX2 
JMP DDSOO,I 



ADDRESS OF ROUTINE 

SET UP BINARY WRITE 

TO POSITION THE CURSOR 

GET SUBCHANNEL 

GET CURSOR ADDRESS POINTER 

ODD SUBCH USE THE OTHER ONE 

GET THE ADDRESS OF LAST 
AND THE BUFFER FILL ADDRESS 
MOVE THE LAST POSITION 



GET THE WHOLE BUFFER ADDRESS 
PUT IT IN THE DD EXTENT 
GET CURSOR MOVE LENGTH WORD 
PUT IT IN THE DD EXTENT 
GET DORQ ROUTINE ADDRESS 
WRITE MODIFIER/EXIT COMMAND 
RETRURN TO INTERFACE DRIVER 



ADDRESS OF THE ROUTINE 

GET THE TIME OUTWORD 

GET THE SENCU ROUTINE ADDRESS 

SAVE IT FOR RETURN 

GET THE EXIT COMMAND 

RETURN DIRECTLY 



USER REQUEST DONE, SENSE WHERE THE CURSOR WAS LEFT 



00205 
00206 
00207 
00210 
00211 
00212 
00213 
00214 
00215 
00216 
00217 



000206R 

001667 

000310R 

000002R 

000363R 

000003R 

000270R 

000004R 

000314R 

000220R 

000256R 



SENCU 



DEF 
STB 
LDA 
STA 
LDA 
STA 
LDA 
STA 
LDA 
LDB 
JMP 



* + l 

EQT8,I 

BNWT 

DEX02,I 

SENCA 

DEX03,I 

SENSL 

DEX04,I 

MODXl 

RDCUS 

CRTN 



READ THE SENSED CURSOR POSITION 



00220 000221R RDCUS DEF *+l 



ADDRESS OF THE ROUTINE 

SAVE TRANSMISSION LOG IN EQT8 

SET UP BINARY WRITE 

IN DEVICE DRIVER EQT EXT 

GET ADDRESS OF CURSOR SENSE 

FOR DD EQT EXT 

GET LENGTH FOR SENSE COMMAND 

PUT IT IN THE DD EQT EXT 

WRITE MODIFIER/EXIT COMMAND 

GET THE ADDRESS OF NEXT 

RETURN TO INTERFACE DRIVER 



ADDRESS OF ROUTINE 
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0202 

0203 

0204 

0205 

0206 

0207 

0208 

0209 

0210 

0211* 

0212* 

0213* 

0214 

0215 

0216 

0217 

0218 

0219 

0220 

0221 

0222 



0223 

0224 

0225 

0226* 

0227* 

0228* 

0229 

0230 

0231 

0232 

0233* 

0234* 

0235* 

0236 

0237 

0238* 

0239* 

0240* 

0241* 

0242 

0243 

0244 

0245* 

0246* 

247* 

0248 

0249 

0250 



00221 
00222 
00223 
00224 
00225 
00226 
00227 
00230 
00231 



000311R 
000002R 
000366R 
000003R 
000273R 
000004R 
000232R 
000315R 
000256R 



LDA 
STA 
LDA 
STA 
LDA 
STA 
LDB 
LDA 
JMP 



RDWCR 

DEX02,I 

CRDBA 

DEX03,I 

CPLNG 

DEX04,I 

COMPL 

M0DX2 

CRTN 



CONTROL WORD FOR READ W/CR 
PASS TO I/F DRIVER 
ADDRESS OF BUFFER 

LENGTH 

ADDRESS OF NEXT ROUTINE 
GET THE EXIT COMMAND 
RETURN TO INTERFACE DRIVER 



COMPLETION ROUTINE, SAVES RETURNED CURSOR POSITION AND EXITS 



00232 000233R COMPL 

00233 000016R 

00234 000360R 

00235 000010 

00236 006004 

00237 000001 

00240 005200 

00241 000375R 

00242 105765 

00243 000274R 

00244 000000 

00245 001667 

00246 002400 

00247 000020R 



DEF *+l 

LDA DEX14,I 

LDB CPAD 

SLA 

INB 

LDB B,I 

RBL 

LDA CUBYT 

MBT D8 



LDB EQT8,I 

CLA 

JMP DDS00,I 



ROUTINE ADDRESS 

GET CURRENT SUBCHANNEL 

GET CURSOR STORAGE POINTER 

ODD SUBCHANNEL. .. 

YES, USE THE OTHER ONE 

GET THE ADDRESS 

MAKE IT A BYTE ADDRESS 

GET BYTE ADDRESS 

MOVE BYTES 



RETRIEVE THE TRANSMISSION LOG 
SET EXIT COMPLETION COMMAND 



TEST FOR SUBCHANNEL ALREADY EQUAL, SKIP MOST OF SETUP 



00250 000261R SUBCK JSB GTSCH 

00251 000016R CPA DEX14,I 
00 252 000177R JMP DORQ,I 
00253 000056R JMP SVSCH 

CONTINUATION PROCESS SELECTION 



GET REQUEST SUBCHANNEL 
COMPARE TO LAST ONE ADDRESSED 
SAME, GO DO USER REQUEST 
DIFFERENT, GO SET UP TERMINAL 



00254 000015R CSOO LDA DEX13,I GET ADDRESS OF NEXT ROUTINE 

00255 000000 JMP A, I GO DO IT 

RETURN TO INTERFACE DRIVER ROUTINE A=MODIFIER/EXIT CMD, 
B=NEXT ROUTINE ADDRESS 

00256 000015R CRTN STB DEX13,I SAVE NEXT ROUTINE ADDRESS 

00257 000312R LDB TO GET THE SETUP TIME OUT 
00260 000020R JMP DDSOO,I 

SUBROUTINE TO RETURN THE SUBCH IN THE A REGISTER 



00261 000000 GTSCH NOP 

00262 001663 LDA EQT4 , I 

00263 000275R AND B3.7K 



GET SUBCHANNEL WORD 

ONLY LOOK AT SUBCHANNEL BITS 
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0251 


00264 


001727 




ALF,ALF 


0252 


00265 


001222 




RAL,RAL ] 


0253 


00266 


000261R 




JMP GTSCH,I 


0254* 










0255* 


CONSTANTS AND 


VARIABLES 


0256* 










0257 


00267 


177761 


DM15 


DEC -15 


0258 


00270 


177775 


DM3 


DEC -3 


0259 


00271 


000001 


Dl 


DEC 1 


0260 


00272 


000004 


D4 


DEC 4 


0261 


00273 


000006 


D6 


DEC 6 


0262 


00274 


000010 


D8 


DEC 8 


0263 


00275 


003700 


B3.7K 


OCT 3700 


0264 


00276 


014037 


TMASK 


OCT 14037 


0265 


00277 


051460 


ASO 


ASC 1,S0 


0266 


00300 
00301 
00302 
00303 


030060 
030162 
030060 
030103 


SORC 


ASC 4,000r000C 


0267 


00304 
00305 
00306 
00307 


030060 
030162 
030064 
031103 


SIRC 


ASC 4,000r042C 


268 


00310 


000102 


BNWT 


OCT 000102 


0269 


00311 


000001 


RDWCR 


OCT 000001 


0270 


00312 


177160 


TO 


DEC -400 


0271 


00313 


000000 


TEMP 


BSS 1 


0272 


00314 


102005 


MODXl 


OCT 102005 


0273* 










0274* 










0275 


00315 


000005 


M0DX2 


OCT 000005 


0276* 










277* 










278* 










0279* 


TERMINAL COMMAND STRINGS 


0280* 










0281 


00273 




CPLNG 


EQU D6 


0282 


00272 




CMLNG 


EQU D4 


0283 


00271 




MSLNG 


EQU Dl 


0284* 










0285 


00316 


015446 


LMPAO 


OCT 15446 


0286 


00317 
00320 
00321 


060440 
030060 
030103 




ASC 3, a OOOC 


0287 


00322 


015446 


LMPAl 


OCT 15446 


0288 


00323 
00324 
00325 


060440 
030064 
031103 




ASC 3, a 042C 


0289 


00326 


000 316R LMPAE 


) DEF LMPAO 


0290 


00327 


000322R 


DEF LMPAl 


0291 


00330 


1 000326R LMPA 


DEF LMPAD 



POSITION TO RIGHT 



CNWD FOR BINARY WRITE 

CNWD FOR READ TO CR, NO ECHO 

4 SEC TIME OUT ON SETUP 

WRITE MODIFIER/EXIT COMMAND 
DO REQ. IN DEX02, END READS 
ON CR, DON'T MODIFY WRITE. 
UNIV. MODIFIER/EXIT COMMAND 
DON'T MODIFY ANYTHING, 
JUST START REQUEST IN EXTENT 



LENGTH OF CURSOR POSITION RQ 
LENGTH OF MARGIN REQUESTS 
LENGTH OF MARGIN SET REQUESTS 

(ESC&) POS. CURSOR FOR LEFT 
MARGIN SET, SUB 



(ESC&) POS. CURSOR FOR LEFT 
MARGIN SET, SUB 1 



ADDRESS OF LEFT MARGIN, SUB 
ADDRESS OF LEFT MARGIN, SUB 1 
ADDRESS OF ADDRESSES 
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0292* 

0293 

0294 

295* 

0296 

0297 



298 
0299 



0300 

0301 

0302 

0303* 

0304 

0305 

0306* 

0307 

0308 

0309 

0310 

0311 

0312 

0313 

0314 

0315* 

0316 

0317 

0318 

0319 

0320* 

0321* 

0322* 

0323 

0324 

0325 

0326 

0327 

0328 

0329 

0330 

0331 

■k * 



0331 015464 LMST OCT 15464 

0332 000331R LMSTA DEF LMST 

0333 015446 RMPAO OCT 15446 



ASC 3, a 037C 



RMPAl OCT 15446 

ASC 3, a 079C 



0334 060440 

0335 030063 

0336 033503 

0337 015446 

0340 060440 

0341 030067 

0342 034503 

0343 000333R RMPAD DEF RMPAO 

0344 000337R DEF RMPAl 

0345 000343R RMPA DEF RMPAD 

0346 015465 RMST OCT 15465 

0347 000346R RMSTA DEF RMST 

0350 015446 CPBUF OCT 15446 

0351 060440 ASC l,a 

0352 000000 CPVAL BSS 4 

0356 000005R CPADD DEF DEX05 

0357 OOOOllR DEF DEX09 
0360 100356R CPAD DEF CPADD, I 
361 000352R CPVAD DEF CPVAL 

0362 000350R CPBFA DEF CPBUF 

0363 000364R SENCA DEF SENCC 

0364 015541 SENCC OCT 15541 

0365 010400 OCT 10400 
0270 SENSL EQU DM3 



RETURN AREA FOR CURSOR SENSE 



00366 000367R CRDBA DEF CRDBF 

00367 000000 CRDBF NOP 

00370 000000 NOP 

00371 000000 NOP 

00372 000000 NOP 

00373 000000 NOP 

00374 000000 NOP 




0375 000761R CUBYT DBR CRDBF+1 

END 



SET L. MARGIN COMMAND (ESC4) 
AND ADDRESS 

(ESC&) POSITION CURSOR FOR R. 
MARGIN SET, SUB 



(ESC&) POSITION CURSOR FOR R. 
MARGIN SET, SUB 1 



ADDRESS OF R. MARGIN, SUB 
ADDRESS OF R. MARGIN, SUB 1 
ADDRESS OF ADDRESSES 

SET R. MARGIN COMMAND (ESC 5) 
AND ADDRESS 

(ESC&) POSITION CURSOR FOR A 
SUB CHANNEL FOR OPERATION 
AREA TO PUT CURSOR COORD. 
ADDR OF CURSOR COORD. SUB 
ADDR OF CURSOR COORD. SUB 1 
ADDRESS OF ADDRESSES 
ADDRESS OF COORDINATE STORAGE 
ADDRESS OF BUFFER 

ADDR OF SENSE CURSOR COMMAND 
(ESCa) SENSE CURSOR COMMAND 
DCl SEND DATA 
CHAR COUNT FOR SENSE COMMAND 



CURSOR READ BUFFER ADDRESS 

SPACE FOR ESC & 

SPACE FOR aY 

SPACE FOR YY 

SPACE FOR rX 

SPACE FOR XX 

SPACE FOR C 

BYTE ADDRESS OF RIGHT BYTE 



NO ERRORS *TOTAL **RTE ASMB 92067-16011** 
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Chapter 5 
Device-Specific Considerations 



The Multiplexer subsystem supports the following HP 
terminals: 2621A/P, 2626A, 2631A/B, 2635, 2675A, and 264X, as well as 
printer support for the 263X and the 7310A. 

Other HP or non-HP devices may be used in conjunction with the 
Multiplexer subsystem. A prerequisite for HP support is the device 
must be hardwired into a point-to-point, asynchronous, bit serial 
environment. However, for these devices it may be necessary for the 
user to write simple device drivers to supplement line protocol and 
specific control characters. 



Handshaking 

Transmission and reception of data or instructions is coordinated by 
firmware controlled handshaking. Handshaking can be viewed from two 
aspects; the Multiplexer firmware or the device can act as the 
transmitter. Some line printers and other devices use hardware 
handshaking between the computer and the terminal/device; these 
devices are not supported. 

The HP 12792A interface card uses firmware on the interface card 

rather than a software driver to accomplish ENQ/ACK handshaking and 

other line protocol necessary to communicate between the MUX card and 

a terminal/device. If the card configuration has handshaking enabled, 

data is transferred to the terminal/device in the following manner: 

The card sends data to the terminal/device in blocks of 80 

characters. Between blocks an ENQ is sent and the firmware 

waits up to 5 seconds for an ACK. If one is received the 

next block is sent. If no response is given, another ENQ is 
s ent. 

If the handshaking is disabled information is transmitted serially 
(character by character) to the terminal/device. 

The other type of handshaking is from terminal/device to the 
Multiplexer card and this is accomplished using DCl an DC2 
handshaking. DCl and DC2 are used for CPU reception in block mode. 
This type of handshaking is controlled by the terminal driver DDV05. 
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DDV12 Lineprinter Driver 

HP supplies a line printer driver (DDV12) similiar to DVR12, although 
some limitations are: 

- no vertical form feed except top of form 

- no over print carriage control ( * in col 1 ) 

- no status requests 



DDV05 Terminal Driver 

When using the HP 264X terminal in the Multiplexer subsystem, the 
device expects to see 8 bits/char data transfers. Users wanting to 
communicate with a 264X or 262X terminal with parity checking should 
configure the interface card for a 7 bit/char data transfer, or 
without parity use 8 bits/char. The 264X terminals require 
handshaking with the ENQ/ACK protocol in order to preserve data 
integrity. These terminals use a blockmode handshaking scheme with 
the CPU receiving DC1/DC2 protocol. A DCl must be detected before the 
information can be sent across the line. 
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Black Box Considerations 

In order to connect a "black box" RS-232-C or RS-423-A device to the 
HP 12792A Multiplexer Interface, the following three criteria must be 
examined: 

RS-232-C and RS-423-A Capability 

Handshaking 

Driver Considerations 

HP offers support to most RS-232-C and RS--423-A compatible devices. 
HP support is limited to correct passage of user's data to/from the 
user's buffer and from/to the specified Multiplexer channel data links 
with insertion/deletion of specifying characters and parity 
information. 

The user should be aware of the line protocol, control sequences, and 
handshaking used by the device. The line protocol must match in order 
for two way communication to exist. The user must understand how 
requests are mapped in as control requests. The user must specify 
whether the terminal/device uses character or block mode handshaking. 

The last consideration requires the user to determine if the 
terminal/device can function using the HP supplied drivers, or if it 
will require a user written device driver. Any specialized control 
which is required by the device not included in the user buffer 
indicates the need for a user written device driver. When functioning 
with user written device drivers, support is also limited to correct 
passage of EQT extent information to and from the user's device driver 
and the correct execution of the device drivers requests. 



Dumb Devices 

If the device requires no additional information beyond what is 
contained in the user's buffer and does not use DCl's, the device can 
be considered a "dumb" device and will be able to operate using DVMOO 
and the default device driver (device driver number one) . Some 
devices that are normally considered dumb devices actually require 
CR/LF delays and will require a user written device driver for proper 
operation. One example of these devices is the common Teletype. 
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Modems 

The HP 12792A Multiplexer has no modem control lines. HP will support 

only full duplex asynchronous modems (USA only) in the 12792A 

Multiplexer Subsystem. All control functions must be set on the 
modem. 

When using modems be aware that if the modem line is disconnected, no 
provision is available to detect the condition. If the user was 
logged on under an RTE-IVB session and the line is disconnected before 
the user logs off, anyone dialing in to that port will be re-connected 
to the session in progress at the time of the previous disconnect. 
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Appendix A 
Device Equipment Table 



The HP 12792A/12828A Multiplexer Subsystem requires a Device Equipment 
Table (EQT) entry for each port on the multiplexer. The entry 
consists of 15 words plus an extension of 17 words, or a total of 32 
words. The EQT entry is configured into the RTE Operating System at 
system generation time. 

During system operation, the device and interface drivers receive 
channel configuration instructions, and passes information to each 
other through the EQT entry for that channel. Table A-1 provides the 
function at each word in the Equipment Table Entry in RTE-IVB and 
RTE-MIII operating systems. 



Table A-1. Equipment Table Entry. 



EQT Words 1-8 



Word 5: 



Word 9: 



standard in the RTE operating environment. 



the status word, bits 7-0 describe the channel's 
status unless it is altered by a device driver: 



Last request timed out 
BREAK key hit 
EOT (control-D entered) 
Reserved for future use, 
should be set to zero 
Parity error or overflow 
Type-ahead data available 
Program scheduling enabled 
Reserved for future use, 
should be set to zero 



Bit 


7: 


Bit 


6: 


Bit 


5: 


Bit 


4: 


Bit 


3: 


Bit 


2: 


Bit 


1: 


Bit 


0: 



On initiation entry this is an optional user 
parameter to the device driver. Thereafter, 
it is the starting address for transfers. 
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Word 10 



On initiation entry, this is an optional user 

parameter to the device driver. Thereafter, 

it is the character length of the data transfer. 



Word 11 



Port Status Word 1 
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Bit 
Bit 

Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 



15 
14 

13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 





Card is busy processing a command 
Deferred abort in process 
(system clear request) 
Waiting for or using DCPC channel 
Buffer flush state 
Using DCPC channel 1 (select code 
I/O transfer in process 
Unsolicited interrupt in progress 
Defer abort flag 
End on CR 
End on RS 
End on CNTL D 
End on DC2 
End on Count 
End on Character 
Edit enable 
Echo enable 



= 6) 



Word 12: 



Bit 15: This EQT is suspended on itself 
Bits 14-0: The address of first EQT suspended, 
waiting for access to the backplane 



Word 13 



Address of EQT extension 



Word 14 



Standard usage: EQT time-out value reset 



Word 15 



Standard usage: EQT running timer 



EQT extension words: (extension word 1 = EQT word 16) 



Word 16: 


Address of the program to schedule 
-1 if none 
if the driver has not been entered 


Word 17: 


Level 1 subroutine return address 


Word 18: 


Level 2 subroutine return address 


Word 19: 


Level 3 subroutine return address 


Word 20: 


Port ID from control 30B optional parameter, 
used in power fail recovery 


Word 21: 


Driver configuration word (from control 33B) 


Word 22: 


Reserved for future use 


Word 23: 


Length of typed-ahead data, in characters 


Word 24: 


Temporary, usually contains the character 
length of the data remaining to be transferred 


Word 25: 


Temporary, usually the second word of the card 
command 
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Word 2 6 



Word 27 



Word 28 



Word 29: 



Word 30: 



Word 31: 



Word 32: 



Temporary, usually the length of the character 
space left in the user buffer 



Port Status Word 2: 

Bit 15: Terminating character has not yet been 

found 
Bit 14,13: 00 = control-D (terminating character) 

01 = <CR> 

10 = <DC2> 

11 = <RS> 

Bits 12-9: Reserved for future use 

Bit 8: Port has key 

Bits 7-0: default status for word 5 bits 7-0 



Device driver command to the interface driver 
(A-Register) 



Device driver timeout, -lO's ms 



Device driver EXEC request 



Device driver I/O buffer address or control 
requests optional parameter 



Device driver buffer length (+words, -chars) 



Any further storage used is defined by the device driver in use. 
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Appendix B 
Device Driver Interfaces 



26XX Screen Mode Device Driver 

This section describes the HP supplied 26XX Screen Mode device driver 
DDV05 used with the Multiplexer interface driver DVMOO. The driver 
supports HP terminals in both character and block mode. All screen 
mode functions (the ENTER key, soft keys, etc) are supported. 
Peripheral devices (CTU's, etc.) are NOT supported by this device 
driver. 

The layout of the user I/O and Control calls are designed to be 

roughly compatible with DVR05. Since this subsystem is be able to 

support a far wider range of terminal capabilities, differences are 
inevitable. 

For generation and initialization information please refer to the 
configuration guide. 



DDV05 User Interface for 26XX Terminals 

The device driver DDV05 utilizes the block mode read capabilities of 
an HP264X or 262X terminal. At boot-up time the device driver reads 
the terminal straps. The strappings may vary between character, block 
line, or block page mode. The character mode is a normal read 
operation, with a carriage return or CNTL-D indicating an 
end-of-record. A carriage return denotes an end-of-record in the 
block line mode, while a record separator denotes an end-of-record in 
the block page mode. Prior to every read request, the device driver 
instructs the interface driver to write a DCl allowing the softkeys to 
be read. 
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Subchannel Assignment 

No support for peripheral devices is given, therefore EQT subchannels 
are ignored. However, for compatibility with existing and future 
products, the subchannel field should be set to zero. 

Control Request Definition 

The control requests accepted by this driver perform various 
functions. Some requests require additional data which is passed to 
the driver through the optional EXEC parameter IPARM. Any control 
request not listed here is passed on to the interface driver for 
execution. The various requests are described as follows: 

Function 11, Line Spacing 

Control function 11 sends a number of CR/LF's to the terminal's 
display as determined by the value of the optional parameter. A 
maximum of 6 3 lines can be spaced in one request. Any value greater 
than 63 will be truncated modulo 64. A zero or negative line count 
results in one CR/LF sent. 

Function 25, Update Terminal Configuration 

Control function 25 (octal) causes the driver to read the strap 
settings on HP terminals. This information is used by the driver to 
assure correct terminal handshake when doing block reads, etc. on HP 
terminals. 

A control 25 is automatically performed when the driver receives its 
first read request. If the terminal straps are subsequently changed 
manually or by escape sequences the user must issue another control 25 
to keep the driver posted of any changes. Failure to do so may result 
in the terminal getting "hung". 

Input/Output Requests 

The action taken by the driver in the processing of I/O requests 
depends on the function code specified in the EXEC call from the user. 
Bits 10 through 6 of the EXEC ICNWD define the function code for the 
request as follows: 
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10 9 8 7 6 


Action taken for READ request 


0X0X0 


input editing enabled, echo off, end transfer 
on <CR> or CTRL-D 




0X1X0 


input editing enabled, echo on 
end transfer on <CR>, or CTRL-D 




0X0X1 


input editing off, echo off, end transfer 
on buffer full 




0X1X1 


editing off, echo on, end 
transfer on buffer full 




1X0X0 


editing off, echo off, end transfer on <CR> 




1X1X0 


editing off, echo on, end 
transfer on <CR> 




10 9 8 7 6 


Action taken for WRITE request 


X X X 


end transfer on end of buffer, add CR/LF if 

last char in buffer is NOT "_" . "_" is not printed 

present as the last char in buffer 


if 


X X X 1 


end transfer on end of buffer, nothing is added to 
the user's buffer 




1 X X X 


end transfer on end of buffer, nothing is added to 
the user's buffer 





For all I/O requests note the following: 

Zero length keyboard entries will not be ignored by the interface 
driver. 

I/O transfers use a character format set up by Control request 30, 
and the terminal must be strapped accordingly. 

Escape and Unit Separator characters are NOT stripped from the 
user's buffer as is done under DVR05. 

Binary type transfers from the display may not be used when the 
terminal is in a block mode. 



B-3 



Read function code 3000B "program enabled block read" is not 
required when doing ESC-d screen reads. However, the driver is not 
as "forgiving" as DVR05 when terminal straps are changed without 
informing the driver. Control function 25 must be issued in order 
to prevent the terminal from being "hung". 



7310 Line Printer Device Driver 

Functional Overview 

This section describes the HP 2631/2635/7310 Line Printer device 
driver DDV12 for use under the Multiplexer driver DVMOO. The driver 
supports both normal (column 1 as carriage control) and transparent 
(column 1 printed) print modes. Carriage control includes 
Top-of-Form, single, double, and triple spacing. 

For Generation and Initialization information consult the HP 12792A 
Multiplexer Subsystem Configuration Guide. 

Write Request Processing 

Write requests to the driver can be made either in a normal or 
transparent mode. The device driver DDV12 is used to make 
HP 2631/2635/7310 printers look like typical line printers to user 
programs. These devices use escape sequences for carriage control 
while standard line printers interpret the first character of each 
line as a carriage control character. The DDV12 device driver 
examines the user's first character and sends the proper escape 
sequence to the printer. In normal mode the first character of the 
line is used to direct the driver to perform carriage control. The 
remainder of the line is transferred to the printer. Carriage control 
characters recognized by the driver are: 



I1 1 1I 



II n II 



1" Go to Top-of-Form 

0" Space one extra line before printing (double space) 
"-" Space two extra lines (triple space) 
all others Single space 
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Transparent mode is selected by setting bit 7 of the EXEC function 
code. In this mode all data is shipped to the printer regardless of 
the data in column 1. 

It should be noted that no processing of the user data is performed 
other than that described above. Since the printer always reacts to 
escape sequences and protocol characters (e.g. ENQ) the user should 
be careful not to place these in the user buffer. 

Control Request Processing 

The only control request processed by this device driver is control 11 
(octal). This is used to either move the paper up (line spacing) or 
move the paper to top-of-form, depending on the value of the optional 
parameter. 

IPARM > move the paper up IPARM lines 

I FARM = move the paper up one line 

IPARM < go to top-of-form 

The maximum number of lines that can be spaced in one request is 63. 
If a request is made to send more than 63 lines the value will be 
truncated modulo 64. (i.e 66 will send 2 lines.) 

All other control requests are passed directly to the interface driver 
for processing. Refer to Chapter 2 for descriptions. 
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Appendix C 
Glossary 



ACK - Acknowledge 



A transmission control character 
transmitted by a receiver as an affirmative 
response to the sender's block mode 
information. 



ASCII 



American Standard Code 
Interchange. 



for Information 



BAUD 



BS 



CONTROL CHARACTER 



CR 



DCl - Device control 



DC2 - Device control 



intervals 
may be of 



ASYNCHRONOUS TRANSMISSION Transmission in which time 

between transmitted characters 
unequal length. Transmission is controlled 
by start and stop elements at the beginning 
and end of each character. 



A unit of signaling speed equal to 
number of discrete conditions or s 
events per second. In asynchr 
transmission, the unit of signaling 
corresponding to one unit interval 
second; that is, if the duration of 
unit interval is 20 milliseconds, 
signaling speed is 50 baud. Baud i 
same as "bits per second" only if 
signal event represents exactly one bi 

Backspace, Control H. 



the 

ignal 

onous 

speed 

per 

the 

the 

s the 

each 

t. 



In the ASCII code, any of the 32 characters 
in the first two columns of the standard 
code table. 

Carriage return. Control M. 

A device control character which is 

primarily intended for turning on or 

starting a peripheral device. The host is 
r'eceiving information. Control Q. 

A device control character which is 
primarily intended for turning on or 
starting a peripheral device. Control R. 
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DIRECT MEMORY ACCESS (DMA) A facility that permits I/O transfers 

directly into or out of memory independent 
of the processor. 



DUMB DEVICE 



DUPLEX 



ECHO 



ENQ - Enquiry 

EOT 
HALF-DUPLEX 

INPUT EDITING 



INTERFACE 



MODEM 



PARITY CHECK 



Device that processes one unit of 
information at a time. It does not contain 
its own local processing capability. In a 
smart device this is typically accomplished 
with a microprocessor. 

Simultaneous two-way independent 
transmission in both directions. Also 
referred to as full-duplex. 

A method of checking the accuracy of 
transmission of data in which the received 
data are returned to the sending end for 
comparison with the original data. 

A transmission control character used as a 
request for a response. Control E. 

End-of-Transmission, Control D. 

A circuit designed for transmission in 
either direction but not both directions 
s imultaneously . 

When enabled, the backspace and delete key 
are enabled and will affect the user's 
buffer. When disabled, the keys are not 
executed but are placed in the user's 
buffer. 

The Multiplexer card making possible 
interoperation between the terminal/device 
and the CPU. 

A device that modulates and demodulates 
signals transmitted over communications 
c ircuits. 

Addition of non-information bits to data, 
making the number of ones in each grouping 
of bits either , always odd for odd parity or 
always even for even parity. This permits 
single error detection in each group. 
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PROTOCOL 



A formal set of conventions governing the 
format and relative timing of message 
exchange between two communicating 
processes. 



TRANSMISSION LOG 



Length of buffer contents to or from the 
MUX card. 



VALID TERMINATOR 



End of data transfer, end of record, for 
example a carriage return. 
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MULTIPLEXER 



Index 



$DVTB 

device driver address table, 4-15, 4-16 

SAM, 4-16 

sample code, 4-27 

table area I, 4-16 



26XX screen mode device driver 
DDV05, 4-4, B-1 



7310 line printer device driver 
DDV12, 4-4, B-4 



A-register 

interface driver, 4-9 

interface driver returns, 4-8 
Abort port's write or control request, 2-21 



B 

B-register 

device driver, 4-11 

interface driver returns, 4-8 

return to interface driver, 4-11 
Baud rate specification, 2-16 
Baud rate generators 

port specification, 2-15 
Binary data reads 

device driver EQT extent, 4-8 
Black box 

compatibility, 5-3 

driver considerations, 5-3 

handshaking, 5-3 

HP support, 5-3 
Break key action, 2-17 
Buffer flush 

abort ports write or control request, 2-21 

buffer flush recovery example, 2-21 

example, 2-21 
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general, 2-21 

remove buffer flush condition, 2-21 



Case study 

cursor position, 4-18 

cursor tracking, 4-18 

device driver writing example, 4-17 

margin set up, 4-17 

minor tasks, 4-18 

task definition, 4-17 
Channel transmission, 1-3 
Clear extraneous commands 

control 26B, 3-2 
Common type-ahead modes, 3-4 
Configure driver responses 

break key action, 2-17 

defining a device driver to this port, 2-18 

example, 2-18 
function code, 2-17 

general description, 2-17 

scheduling, 2-17 

sending read configuration into the card, 2-18 

specifying unique read request type, 2-18 

type-ahead action, 2-17 

type-ahead feature specification, 2-17 
Continuation entry 

device driver, 4-22 

system abort request, 4-6 

test, 4-22 
Control request 

buffer flush, 2-21 

configure driver responses, 2-17 

device initialization, 2-15 

disable schedule, 2-20 

dynamic status, 2-24 

enable scheduling, 2-19 

file manager format, 2-14 

flush input buffer, 2-22 

function codes, 2-14 

general format, 2-13 

required parameters, 2-14 

restore output processing, 2-21 

set port's ID, 2-15 

set program address, 2-22 

set read type, 2-23 

set timeout, 2-20 
Control request to the MUX, B-5 

full type-ahead, 3-5 

no type-ahead mode, 3-5 
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write request, B-5 
Control word 

general, 2-2 

read request, 2-6 

write request, 2-7 
Cursor position 

case study, 4-18 
Cursor tracking 

case study, 4-18 

D 

Data overrun error 

read error, 3-9 
Data transfers 
packing, 4-2 

parity, 4-2 
DC1/DC2 

handshaking, 5-2 

DDV0 5 

block line mode, B-1 

block mode terminal device driver, 4-4 

block page mode, B-1 

block read, 4-4 

character mode, 4-4, B-1 

control request definition, B-2 

data transfers, 5-2 

DCl, DC2, 4-4 

editing, 4-4 

handshaking requirements, 5-2 

I/O requests, B-2 

line spacing, B-2 

read requests, B-3 

special I/O considerations, B-3 

status checking, 4-4 

subchannel assignment, B-2 

terminal driver, 5-2 

update terminal configuration, B-2 

user interface for 26XX terminals, B-1 

write requests, B-3 

DDV0 5 vs DVR05 

comparison, B-1 
DDV12 

carriage control, 4-4 

changing device type, 4-4 

control request processing, B-5 

functional overview, B-4 

limitations, 5-2 

line printer driver, 5-2 

line spacing, B-5 

normal print mode, B-4 
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paper advance, B-5 
transparent mode selection, B-5 
transparent print mode, B-4 
write request processing, B-4 
Device driver 

26XX screen mode device driver, B-1 

7310 line printer device driver, B-4 

A-register, 4-7 

adding device drivers, 4-15 

B-register, 4-7 

base page locations, 4-7 

case study, 4-17 

changing device type, 4-4 

character mode, 4-4 

concept, 4-1 

continuation entry, 4-22 

correct status, 4-3 

customizing, 4-2 

DDV05, 4-4 

DDV12, 4-4 

device address table, 4-15 

device driver address table, 4-27 

device driver writing example, 4-17 

double buffering, 4-14 

dynamic switching, 4-2 

EQT, 4-3 

EQT word 1, 4-8 

EQT word 10, 4-7, 4-15 

EQT word 14, 4-7, 4-15 

EQT word 15, 4-15 

EQT word 2, 4-8 

EQT word 3, 4-8 

EQT word 4, 4-8 

EQT word 5, 4-13 

EQT word 7, 4-14 

EQT word 8, 4-14 

EQT word 9, 4-7, 4-15 

EQT words 2-4, 4-7, 4-8 

EQT words 4-10, 4-7 

EQT words 6-8, 4-7 

equipment type code, 4-13 

exit commands, 4-10 

final completion return to the interface driver, 4-27 

I/O considerations, 4-5 

interface driver concept, 4-1 

location and size of device drivers, 4-16 

modify EQT, 4-12 

operation, 4-19 

operation flow, 4-20 

output a set up string to terminal, 4-24 

perform the original user request, 4-25 

read cursor position, 4-26 

Index-4 



MULTIPLEXER INDEX 



Read/Write control request considerations, 4-5 

request legality, 4-3 

request types, 4-14 

restrictions and requirements, 4-5 

return routine, 4-25 

sample listing, 4-27 

sequence of actions, 4-19 

set up device driver EQT extent pointer, 4-22 

set up on first entry, 4-23 

special sequences, 4-3 

status definitions, 4-13 

subchannel determination, 4-23 

system abort request, 4-6 

tasks, 4-3 

transmission log, 4-3 

unrecognized control request, 4-6 

use, 4-1 

user request, 4-3 

user written device driver considerations, 4-5 

valid labels, 4-16 

writing example, 4-17 
Device driver address table 

$DVTB, 4-15 

format, 4-16 

general description, 4-15 

valid device driver labels, 4-16 
Device driver EQT extent 

binary data reads, 4-8 

general description, 4-8 

pointers set up, 4-22 
Device driver interface 

general definition, 4-5 
Device initialization 

configure driver responses, 2-15 

enable scheduling, 2-15, 2-19 

set port ID, 2-15 
Disable schedule 

example, 2-20 

general description, 2-20 
DMA 

interface driver, 4-3 

Dumb device, 5-3 
DVMOO 

interface driver, 4-3 
Dynamic status 

character length of any TA data, 2-24 

example, 2-25 

general, 2-24 

port's status, 2-24 
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E 

Enable scheduling 

conditions, 2-19 

example, 2-19 

general description, 2-19 
EQT 

modify, 4-12 

set up on first entry, 4-23 

word 1, 4-8 

word 10, 4-7, 4-15 

word 14, 4-7, 4-15 

word 15, 4-15 

word 2, 4-8 

word 3, 4-8 

word 4, 4-8 

word 5, 4-13 

word 7, 4-14 

word 8, 4-14 

word 9, 4-7, 4-15 

words 2-4, 4-7, 4-8 

words 4-10, 4-7 

words 6-8, 4-7 
EQT set up on first entry 

cursor position, 4-23 

device driver, 4-23 

sample code, 4-23 
EQT word 10 

device driver, 4-15 

length of secondary buffer, 4-15 
EQT word 14 

device driver, 4-15 
EQT word 15 

device driver, 4-15 
EQT word 4 

subchannel, 4-12 

EQT word 5 

equipment type code, 4-13 

equipment type code and status, 4-12 

interface driver, 4-8 

status definitions, 4-13 
EQT word 6 

double buffering, 4-14 

request types, 4-14 
EQT word 7 

device driver, 4-14 
EQT word 8 

device driver, 4-14 
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EQT word 9 

address of secondary buffer, 4-15 

device driver, 4-15 
Equipment type code 

EQT word 5, 4-13 
Error checking 

dynamic status, 3-7 

failure analysis, 3-9 

I/O status, 3-7 

I/O status request returns, 3-8 
Error recovery 

general, 3-7 
EXEC call 

control word, 2-1, 2-2 

from Assembly language, 2-8 

from FORTRAN, 2-9 

from PASCAL, 2-10 

function code, 2-2 

request codes, 2-1 
Exit commands 

device driver, 4-9, 4-10 

error types, 4-9 

new device driver request, 4-11 



Failure analysis, 3-9 
Final completion 

return to the interface driver sample code, 4-27 
Flush input buffer 

example, 2-22 

flush active, 2-22 

flush all input buffers on that port, 2-22 

general description, 2-22 
Full type-ahead 

example, 3-5 

general description, 3-5 

program scheduling, 3-5 
Function 11 

line spacing, B-2 

Function 25 

update terminal configuration, B-2 

Function code 

EXEC call, 2-2 

H 

Handshaking 

DCl, DC2, 5-1 

enable/disable port for ENQ/ACK, 2-16 
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ENQ/ACK, 5-1 
terminal, 5-2 

HP supplied device driver 

26XX screen mode device driver, B-1 
7310 line printer device driver, B-4 

HP supplied drivers 
DDV05, 4-4 



DDV12, 4-4 
Hung terminals, B-2 



I/O request 

echoing, 2-4 

editing, 2-4 

general, B-2 

terminators, 2-4 
I/O status 

example, 3-7 

general, 3-7 

parameters, 3-7 

request returns, 3-8 

status word 4, 3-7 
Interface definitions 

A-register, 4-7 

B-register, 4-7 

base page location, 4-7 

device driver, 4-7 

EQT word 10, 4-7 

EQT word 14, 4-7 

EQT word 9, 4-7 

EQT words 2-4, 4-7 

EQT words 4-10, 4-7 

EQT words 6-8, 4-7 

general description, 4-7 
Interface driver, 3-3 

A-register, 4-3 

A-register return, 4-8 

B-register, 4-3 

B-register return, 4-8 

concept, 4-1 

device address table, 4-15 

device driver, 4-16 

device driver EQT word 1 return, 4-8 

device driver EQT word 2 return, 4-8 

device driver EQT word 3 return, 4-8 

device driver EQT word 4 return, 4-8 

DMA, 4-3 

DVMOO, 4-3 

EQT word 5, 4-8 

EXEC call handling, 4-3 
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exit command, 4-9 

memory requirements, 4-16 

program scheduling, 3-3 

read function modifiers, 4-10 

request timer return, 4-8 

return to the interface driver, 4-7 

RTE, 4-3 

status for user, 4-8 

system abort requests, 4-6 

transmission log, 4-3 

use, 4-1 

user request and continuation entries, 4-7 

user transmission log return, 4-8 

write function modifier bits, 4-10 

write function modifiers, 4-10 
Interface driver concept 

device driver, 4-1 
Interface driver tasks 



general description, 4-2 
interface control, 4-3 

operating system interface, 4-3 



Line printer 

device carriage control, 4-4 
Line printer driver 

DDV12, 5-2 



M 

Margin setup 

case study, 4-17 
Memory requirements 

interface driver, 4-16 
Minor tasks 

case study, 4-18 
Modems, 1-4 

limitations, 5-4 

session environment, 5-4 

support, 5-4 
Modes 

normal mode, 3-1 

type-ahead, 3-1 
Multiplexer interface responsibilities, 4-2 
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N 



No type-ahead mode 

example, 3-5 

general, 3-5 

standard RTE mode, 3-5 
Normal mode 

general description, 3-1 







Operation flow 

device driver, 4-20 
Output a set up string to terminal 

sample code, 4-24 
Outstanding data, 2-22 
Overflow error 

error recovery, 3-7 



Parity error 

error recovery, 3-7 

PASCAL 

example, 2-10 

PRMPT 

program scheduling, 3-4 
Program scheduling 

B-register, 3-3 

break key, 3-3 

EQLU, 3-3 

EQT word 4, 3-3 

explanation, 3-3 

normal break mode, 3-3 

PRMPT, 3-4 

programmatic setting, 3-3 

R$PN$, 3-4 

TRMLU, 3-3 



R 



R$PN$ 

program scheduling, 3-4 
Re-enable schedule 

example, 2-20 
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Read cursor position 

device driver, 4-26 

sample code, 4-26 
Read errors, 3-9 

Read function modifier interface driver, 4-10 
Read function modifiers 

bit field definitions, 4-11 
read configurations, 4-11 

Read request, 2-6 

Request timer interface driver, 4-8 
Request types EQT word 6, 4-14 
Restore output processing 

buffer flush recovery, 2-21 

example, 2-21 

general, 2-21 
Return routine 

device driver, 4-25 
Return to interface driver 

A-register, 4-9 

B-register, 4-11 

RTE interface driver, 4-3 



SAM 

$DVTB, 4-16 
Selected EQT definitions 

equipment type code and status, 4-12 

subchannels, 4-12 
Set port ID 

baud rate, 2-15, 2-16 

ENQ/ACK handshaking, 2-16 

example, 2-16 

function code, 2-15 

general description, 2-15 

number of bits/char, 2-15 

port number, 2-16 

stop bits, 2-16 
Set program address 

example, 2-23 

general description, 2-22 

scheduling an unsolicited interrupt, 2-22 
Set read type 

configure a read without executing a read request, 2-23 

example, 2-23 

general, 2-23 
Set timeout 

example, 2-21 

general description, 2-20 
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Set up device EQT extent pointers 

sample code, 4-22 
Special considerations 

binary transfers, B-3 

character format, B-3 

escape and unit separator treatment, B-3 

screen reads, B-4 

zero length reads, B-3 
Standard RTE mode 

no type-ahead, 3-5 
Status definitions 

EQT word 5, 4-13 
Status for user interface driver, 4-8 
Status word 4 

I/O status, 3-7 
Subchannel determination 

new request entry, 4-23 
sample code, 4-23 

System abort request 

continuation entry, 4-6 

EQT word 2, 4-6 

EQT word 6, 4-6 

general description, 4-6 
System defined timeout 

EQT word 14, 4-15 
System or subsystem crashes 

system abort request, 4-6 



Table area I 

$DVTB, 4-16 
Task definition 

case study, 4-17 
Terminal driver 

DDV05, 5-2 
Throughput, 1-3 
Timeout clock 

EQT word 15, 4-15 
Timeouts 

error recovery, 3-7 
Transmission log 

B-register, 4-11 
Transparent mode selection, B-5 
Type-ahead 

action taken on available type-ahead data, 2-17 

cancel type-ahead data, 2-17 

description, 3-1 

enable, 2-17 

example, 3-2 

schedule, 2-17 
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Type-ahead with flush on break mode 

control function 27, 3-6 
example, 3-6 
general, 3-6 
Type-ahead with scheduling 
control function 27, 3-6 
example, 3-6 
general, 3-6 



U 

User transmission log 

interface driver, 4-8 
User written device driver considerations, 4-5 



W 



Write function modifier bits 
read related fields, 4-10 

Write modifier 

interface driver, 4-10 

Write request, 2-7 

Write request processing 
normal mode, B-5 
transparent mode, B-5 
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